Skip to content

feat(vault): timelock governance after setup - #258

Open
hpmaxi wants to merge 3 commits into
feat/oracle-timelockfrom
feat/vault-setup
Open

hpmaxi wants to merge 3 commits into
feat/oracle-timelockfrom
feat/vault-setup

Conversation

@hpmaxi

@hpmaxi hpmaxi commented Oct 17, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Governance could change the vault's custodian, roles and admin, and lower the notice or the wind-down delay, all at once.

Now role grants, admin hand-overs, revoking a manager role, the custodian, and lowering the notice or the wind-down delay (now at least 7 days) wait for the timelock. Pause and unpause, the deposit cap in both directions, raising the notice or the wind-down delay, and revoking an operational role are instant. Wiring is instant in a setup window that closes once, and the vault takes no deposit until that window is closed and its wiring checks pass, so every deposit is covered by the timelock. During an active wind-down nothing timelocked is proposed or applied, revoking the manager role included.

Part of #108: finish_setup checks the wiring, and the harness deploy fails without it. A later runbook PR closes it.

Changes

  • finish_setup checks the token and oracle bindings, the sole manager role, an empty share supply, the allowlist and the compliance binding, and refuses while a hand-over offered during setup is pending
  • request_deposit is refused with SetupOpen until then; nothing is proposed during setup
  • After setup, the custodian, grants, revoking manager, admin hand-over, a lower notice and a lower wind-down delay go through propose_change; their bounds are checked again when they apply
  • Revoking treasury or guardian, raising the notice or the wind-down delay, and the deposit cap stay instant; set_role_admin is always refused
  • Wind-down delay: minimum and default 7 days; a short_wind_down build for local tests drops it to zero and says so in its metadata
  • The harness deploy sets the custodian and finishes the vault's setup, and fails loudly if it cannot

Deviations

  • Contract, tests and harness share one commit, so no commit leaves the harness broken.
  • The wiring check also refuses a token or oracle bound elsewhere or still in setup, and a token with shares outstanding.
  • Only revoking manager waits; other vault roles revoke at once.
  • A wind-down delay below the floor answers WindDownDelayTooShort before UseTimelock.
  • An outsider's set_custodian fails on UseTimelock before any signature, so that harness guard uses propose_change.
  • The notice-lowering harness test sits in the notice block.
  • Extra tests: hand-over expiry and window, events, bounds at apply, a wind-down with a pending manager revoke.

Acceptance criteria

  • request_deposit is refused with SetupOpen until finish_setup
  • finish_setup checks the token and oracle bindings, the sole manager role, an empty share supply, the allowlist and the compliance binding, and refuses while a hand-over offered during setup is pending
  • After setup: custodian changes, grants, revoking manager, admin hand-over, and lowering the notice or the wind-down delay go through propose_change; raising is instant; revoking treasury or guardian is instant; the deposit cap stays instant
  • The wind-down delay is at least 7 days, and that is the default
  • The harness deploy finishes setup and refuses to report success otherwise

Test plan

Automated tests

  1. cargo test --locked: all green, with 359 tests in async-vault (31 new), 80 in nav-oracle and 51 in share-token.
  2. Build the fixture, the token and the token probe as docs/TESTING.md says, then cargo test --locked -p async-vault --features upgrade_wasm with_wasm: 5 passed. CI does not run this yet.
  3. cargo check -p async-vault --features short_wind_down compiles; that WASM's metadata reads build: short wind-down; local tests only.
  4. On a local quickstart network: HARNESS_NETWORK=local npm run deploy -w scripts/harness, then test:happy-path (24 passed) and test:guards (46 passed).

Manual verification

  1. Run HARNESS_NETWORK=local npm run deploy -w scripts/harness. It prints "vault setup finished" before "wrote deployed.local.json".
  2. Call the vault's setup_open: it returns false. Simulate set_custodian from any account: it is refused with Error(Contract, #6065) (UseTimelock).

Breaking changes

Deposits need finish_setup; until then request_deposit is refused with SetupOpen (6064). The development deploy from environments.toml cannot finish setup, so a working local vault comes from the harness deploy. After setup, set_custodian, grant_role, transfer_admin_role with a non-zero ledger, revoking manager, and lowering the notice or the wind-down delay are refused with UseTimelock (6065); set_role_admin is always refused. The wind-down delay defaults to 7 days and cannot go lower (6069). New error codes 6064–6067, 6069 and 6074. The console still calls the instant setters and adapts at the testnet redeploy.

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 17, 2026 2:02pm UTC

Request Review

@hpmaxi
hpmaxi marked this pull request as ready for review October 17, 2026 14:20

This branch was successfully deployed

1 active deployment
Preview — cbf5c369 Deployed Oct 17, 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