Skip to content

feat(compliance): timelock rule changes - #263

Open
hpmaxi wants to merge 5 commits into
feat/legal-transferfrom
feat/compliance-timelock
Open

hpmaxi wants to merge 5 commits into
feat/legal-transferfrom
feat/compliance-timelock

Conversation

@hpmaxi

@hpmaxi hpmaxi commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Governance could add a compliance module that refuses every mint, or unbind the token, at once. Module, binding and admin changes on the compliance contract now wait for the vault's timelock after setup, like every other change in the kit.

Changes

  • Setup window, bind_vault and finish_setup on the compliance contract
  • A two-step admin hand-over, instant during setup and timelocked after it; setup cannot close while one is pending
  • Module and binding changes go through propose_change / apply_change on the vault's clock; direct calls answer UseTimelock after setup
  • The vault's finish_setup and health().compliance_bound need a kit compliance contract on its clock; one that does not answer VaultBinding is accepted as an external module
  • The harness deploy wires the order, npm run extend covers the compliance queue, and the guards check the refusal and the queue
  • The design doc records a limit: a module that starts failing during a wind-down blocks the claims that burn shares, and cannot be removed while the wind-down runs

Deviations

  • The error enum is ComplianceContractError (8001–8011): OpenZeppelin's ComplianceError is already in this contract's spec, and two enums with one name break the generated TypeScript client.
  • The governance logic sits in its own module, like the token's and the oracle's.
  • Instead of the plan's controls.rs test, the wiring tables gain two cases (bound elsewhere, setup open), and a test accepts an external compliance contract.
  • Extra tests: every change kind, notice, pause, auth, events, one clock read per call, TTL, hand-over window; two guards on the network.
  • Also updated docs the plan did not list.

Acceptance criteria

  • bind_vault once during setup; finish_setup needs a bound vault and closes the window for good
  • After setup, add_module_to, remove_module_from, bind_token and unbind_token are refused with UseTimelock
  • propose_change, cancel_change, apply_change and pending_changes follow the vault's clock
  • The vault's finish_setup requires a kit compliance contract bound to it with setup finished
  • The admin hands over in two steps: instantly during setup, through the timelock after it; finish_setup refuses while a hand-over is pending
  • The harness deploy wires the order

Test plan

Automated tests

  1. CARGO_TARGET_DIR=<repo>/target SOROBAN_SDK_BUILD_SYSTEM_SUPPORTS_SPEC_SHAKING_V2=1 nix develop -c cargo test --locked -p compliance: 29 tests pass, 26 of them in test::changes.
  2. The same with --workspace: async-vault 371, compliance 29, nav-oracle 80, share-token 64, timelock 19, identity-verifier 6 and storage 6 pass.
  3. After building the Wasm, the fixture and both probes: cargo test --locked -p async-vault -p nav-oracle --features upgrade_wasm with_wasm passes 5 + 2.
  4. On a fresh local network, npm run deploy -w scripts/harness prints compliance bound to the vault, setup finished and "compliance_bound":true; then test:happy-path (24/24), test:guards (48/48) and test:wind-down (6/6) pass.

Manual verification

On the same network, governance proposed an UnbindToken change through the CLI. npm run extend printed compliance pending change 3 live until ledger 518975. A direct unbind_token returned Error(Contract, #8005) (UseTimelock). After cancel_change, pending_changes read [] and the token stayed bound.

Breaking changes

After finish_setup, the compliance contract refuses add_module_to, remove_module_from, bind_token, unbind_token and a non-zero transfer_admin_role with UseTimelock (8005). A deployment must bind the compliance contract to the vault and finish its setup before the vault's finish_setup, or the vault refuses with SetupIncomplete. The compliance contract's spec gains entrypoints, events and errors 8001–8011, so its client must be regenerated. The console does not call the compliance contract.

Checklist

  • Self-reviewed my own diff
  • Tests added or updated
  • Docs updated (if applicable)
  • No unrelated changes bundled in

Screenshots

None.

@vercel

vercel Bot commented Oct 17, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
strata-vault-kit-app Ready Ready Preview Oct 20, 2026 5:43pm UTC

Request Review

@hpmaxi
hpmaxi marked this pull request as ready for review October 17, 2026 19:48

This branch was successfully deployed

1 active deployment
Preview — c546cc2d Deployed Oct 20, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant