Repository navigation
Conversation
OpenZeppelin extends a balance or freeze entry when it reads it, not when it creates it, so a new one started at the network's minimum lifetime and the next caller paid to extend it. On testnet that minimum is about seven days, and a transaction simulated before the entry existed then failed for too low a fee; the first redemption, which creates the vault's own share balance, hit this. Every token call that writes a balance or a freeze entry now reads it back through OpenZeppelin's own reads, so a new entry reaches its extend target in the call that creates it. The tests set the ledger's minimum lifetime to testnet's.
A role grant writes up to four persistent entries: the account's role, its place in the member list, the member count and the list of roles. OpenZeppelin extends them when it reads them, not when it creates them, so the first keeper or investor whose call checked the role paid to extend it from the network's minimum. Every grant the vault, the share token and the oracle make (in their constructors, in grant_role and in an applied GrantRole change) now reads those entries back through OpenZeppelin's own reads, so the granter pays and each entry reaches the role lifetime in the same call.
The kit spec said OpenZeppelin extends balances when it writes them; it extends them only when it reads them. The TTL policy now says the contracts read back each balance, freeze and role entry they write, and lists each network's minimum lifetime and longest extension (testnet about 7 days, mainnet about 120, read over RPC), what that means on each network, why the kit keeps one set of values everywhere, who pays, and what frontends should do. The testing guide lists the new tests.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
The mainnet test only checked that a new balance starts at the network's 120-day minimum. It now also checks the spec's claim about renewals: a read on day 90 leaves the balance alone, and a read on day 91 renews it to 30 days. A second test does the same for a role, which a role check renews on day 31 and not on day 30. Test comments are one line each.
The TTL policy said every role check renews a role's entries and that any read or write extends an entry. A role check extends only that account's role entry; the member-list slot, the member count and the role list are extended only by grants and by calls that list role members. Writing an entry never extends it on its own: the kit's storage helpers extend on every read and write, OpenZeppelin only when it reads an existing entry, so the kit reads back what it creates. A revoke moves entries with plain writes and extends none of them.
hpmaxi
marked this pull request as ready for review
October 20, 2026 05:59
balance and total_supply now extend the share token's instance before they read, like every call that moves shares. A keeper's wind-down round, or a claim that burns nothing, only reads the token, so a quiet wind-down could otherwise let the token's instance archive.
# Conflicts: # docs/kit-spec.md
…_supply Both are read-only views, and a view's doc carries no authorization section, like the oracle's views.
This was referenced Oct 20, 2026
2 tasks
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes #327
A new share balance or role entry started at the network's minimum lifetime, and the next call that read it paid to extend it. On testnet that minimum is about seven days, so a transaction simulated before the entry existed failed for too low a fee. The first redemption, which creates the vault's own share balance, hit this. OpenZeppelin extends an entry when it reads it, not when it creates it.
Now every call that writes a share balance or a freeze, and every role grant in the vault, the token and the oracle, reads back what it wrote through OpenZeppelin's own reads. A new entry reaches its extend target in the transaction that creates it, and the same code runs on every network. The kit spec's TTL policy lists each network's settings and what frontends should do.
Changes
mint,burn,transfer,transfer_from,forced_transfer,legal_transferandrecover_balanceset_address_frozen,freeze_partial_tokens,unfreeze_partial_tokens, and the freezesrecover_balancecarriesgrant_roleand in an appliedGrantRolechangebalanceandtotal_supplyextend the token's instance before they read, so a wind-down that only reads balances keeps the token aliveDeviations
burnand the sending side of every transfer are read back: OpenZeppelin writes a zero balance for an account that sends nothing and held nothing.Acceptance criteria
Test plan
Automated tests
cargo test --locked: 705 passed (440 vault, 101 oracle, 96 token, 36 compliance, 7 identity verifier, 19 timelock, 6 storage). 24 are new. On the base, the 21 testnet ones fail with each new entry at 120,959 ledgers, the network minimum; the two mainnet ones pass there too, since that minimum is longer than any target. The last one lets the token's instance fall below its threshold and fails on the base, where abalanceread does not extend it. Each commit passes on its own.cargo clippy --locked --all-targets -p share-token -p async-vault -p nav-oracle -- -D warnings, and the vault with--features short_wind_down: clean.Manual verification
docker run --rm -d -p 8000:8000 --name stellar-local stellar/quickstart --local --enable core,rpc. Its minimum lifetime is testnet's, 120,960 ledgers.stellar contract build, thenCARGO_TARGET_DIR=target/short-wind-down stellar contract build --package async-vault --features short_wind_down.npm run build:clients, thenHARNESS_NETWORK=local npm run deploy -w scripts/harness, thentest:happy-path,test:guardsandtest:wind-downwithnpm run <script> -w scripts/harness.Wasm sizes: share token 42,919 bytes (was 42,490), oracle 33,080 (was 32,937), vault 73,163 (was 73,041). Compliance and identity verifier are unchanged.
Breaking changes
No entrypoint, argument, event or error changes. Fees move: on testnet, the call that creates a share balance, freeze or role entry pays for 30 days (90 for a role) instead of about 7, and the next caller no longer pays the difference.
Checklist
Screenshots
None.