Skip to content

feat: share one timelock across the contracts - #245

Open
hpmaxi wants to merge 3 commits into
mainfrom
feat/shared-timelock-crate
Open

hpmaxi wants to merge 3 commits into
mainfrom
feat/shared-timelock-crate

Conversation

@hpmaxi

@hpmaxi hpmaxi commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Summary

aha G: only the vault could be upgraded, and its admin changed settings at once.

Our reply: the share token and the oracle become upgradeable under the vault's timelock, with one crate holding the rules for every contract. This PR adds that crate and moves the vault's upgrades onto its change queue; the token and the oracle follow in the next PRs.

Changes

  • New timelock crate: delay bounds, a queue of pending changes, pause accounting, a setup window and the clock traits
  • Vault upgrades go through propose_change, cancel_change and apply_change; pending_changes lists what waits
  • Nothing is proposed or applied during an active wind-down
  • A delay change checks the notice again when it applies
  • The vault reports its clock through timelock_clock()
  • Day-based constants use timelock::DAY_DURATION
  • CI runs the Wasm upgrade tests

Deviations

  • The queue holds up to 16 changes, but both vault change kinds are code changes, so the vault holds one at a time for now.
  • The vault closes its setup window in its constructor.
  • Setup and binding refusals cannot happen in the vault and map to NotInitialized (6030).
  • The kit spec's Invariant 8 still lists the wind-down delay bound.
  • Extra test: cancelling publishes ChangeCancelled.

Acceptance criteria

  • Changes wait at least the vault's upgrade delay, never less than the notice, with paused time not counted
  • Several changes can wait at once; one code change at a time
  • Nothing is proposed or applied while the vault winds down
  • The vault exposes timelock_clock() through a contract trait
  • Every existing upgrade test passes on the new entrypoints, and CI runs the Wasm upgrade tests

Test plan

Automated tests

  1. cargo test --locked: all green, with 19 tests in timelock and 248 in async-vault.
  2. stellar contract build --manifest-path fixtures/upgrade-target/Cargo.toml, then cargo test --locked -p async-vault --features upgrade_wasm with_wasm: 3 passed. The CI step "Run the upgrade tests against built Wasm" runs the same two commands. Its commit is not pushed yet: the push token lacks the workflow scope.

Manual verification

  1. Run stellar contract build --package async-vault.
  2. The exported functions include propose_change, cancel_change, apply_change, pending_changes and timelock_clock, and no *_upgrade function.

Breaking changes

The change queue replaces propose_upgrade, propose_upgrade_delay, cancel_upgrade, apply_upgrade and upgrade_proposal, and three Change* events replace the five Upgrade* ones. Codes 6056 and 6057 become ChangeNotFound and ChangeNotReady; 6063 TooManyPendingChanges is new. Fresh deployments only: there is no in-place upgrade from the current testnet vault. The app is unchanged: it builds against testnet's contracts.

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 16, 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 16, 2026 11:04pm UTC

Request Review

@hpmaxi
hpmaxi marked this pull request as ready for review October 16, 2026 23:09

This branch was successfully deployed

1 active deployment
Preview — 2649de5e Deployed Oct 16, 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