Repository navigation
Wire the vault's token role and allowlist for production #108
Description
Priority
Medium — should be addressed soon
User story / Problem statement
Two grants have to happen after deployment or the vault cannot do its job, and neither is a call this
repository makes in production.
The vault mints and burns shares, so it needs the share token's manager role. Cancellation returns
escrowed shares through the token's checked transfer, which verifies both sides, so the vault must also
be an allowlisted holder in its own right. Without either, a fresh deployment takes deposits and can
neither deliver shares nor give them back.
In development both are wired in environments.toml. In production neither is ours. The architecture
says the token role belongs to a Manager contract and never a human key, and that contract does not
exist yet. The allowlist belongs to the operator's identity registry, which on mainnet is an external
ERC-3643 registry owned by a trusted issuer, not the testnet stub in this repository. Registering the
vault there is an onboarding request in someone else's system, with someone else's timeline.
Expected outcome
The deployment sequence names both grants, says who performs each, and fails loudly when either is
missing rather than at the first claim.
Acceptance criteria
- The runbook lists both grants as deployment steps, with the authority that performs each.
- A deployed vault can report whether it holds the token's manager role and whether it is
allowlisted, so the gap is visible before an investor finds it. - The deployment script verifies both after wiring and refuses to report success otherwise.
- The production path is written down: the Manager contract for the role, and the operator's
identity registry for the allowlist, including that the second is an external request.
Technical notes
The allowlist requirement is new. It arrived with cancellation, because returning shares uses the
checked transfer rather than a forced one, which is what makes a frozen or de-listed controller take
the cash path instead. Earlier notes claimed the vault had to stay allowlisted and were wrong at the
time; the claim is true now.
Refs: architecture §3 (share token, compliance module) · §10 (deployment)
Activity
hpmaxi commentedon Sep 10, 2026
The grants cannot live in
environments.toml. Eachafter_deployline is appended tostellar contract invoke --id <this contract> --, so a line can only call the contract whose block it sits in. Both grants target other contracts while needing the vault's own address, and the vault deploys last because its constructor takes the others. A post-deploy script owns them. Attempting it in the toml fails the build withunexpected argument '--id' found.pragalli commentedon Oct 14, 2026
Note on the Manager contract mentioned above: the design document dropped it in fbfc389 ("docs: reconcile design document with contracts", 2026-09-24). It now states the share token's
managerrole is held only by the vault. The production path for that grant is therefore the vault, not a separate Manager contract; the description and the second acceptance criterion should be read that way. The identity registry half of this issue is unchanged, and #238 evaluates whether the external ERC-3643 route is reachable in time for mainnet.hpmaxi commentedon Oct 23, 2026
Covered by the open stack, so this closes with #260.
finish_setuprefuses until the vault is the share token's onlymanager(#258, merged intofeedback).health()reportssole_token_managerandallowlisted, and the harness deploy fails on a wiring gap before it writes the record (#260). The vault itself holds themanagerrole, as noted above, and the kit spec says a production identity registry replaces the testnet verifier (#278); #238 picks that registry. With #264, returning escrowed shares no longer needs the vault on the allowlist: only a delisted holder's conversion does.