Guardian & governance
The complete admin surface, three functions, none of them touching funds.
Every basket has a guardian: an immutable address (the protocol Safe,
0xc7aB…Ec02)
whose complete set of powers is:
| Function | What it does | What bounds it |
|---|---|---|
setMintPaused(bool) | Pauses/unpauses minting only | Redemption is untouched: a paused basket can always be unwound |
setSupplyCap(uint256) | Moves the supply cap | Never above the immutable maxSupplyCap ceiling fixed at deploy (1M tokens) |
setFeeRecipient(address) | Redirects future mint fees | Fees only, no access to vault funds |
That is the whole list. Explicitly impossible, because the functions do not exist: changing constituents or units, changing the fee bps, withdrawing or sweeping constituents, pausing redeem, upgrading the contract.
The deploy scripts hard-refuse EOAs for the guardian and fee-recipient roles; they must be contracts (Safes). The guardian address is immutable per basket: there is no "fix it later", which is exactly the point.
Why a guardian at all?
Two operational needs, both damage-bounding rather than value-extracting:
- Pause minting: if anything looks wrong (a bad deploy, an issue in a constituent), stopping new exposure while everyone remains free to exit is the correct emergency lever. The rollback stance is built on it.
- The supply cap: deposits are deliberately capped while the protocol is unaudited, rising along a public roadmap with demonstrated traction and audits. Raising the cap is a Safe transaction, public on Blockscout, and requires explicit human sign-off. Lowering it is always allowed and never affects redemption or existing holders.
Governance today
Robinwood Stocks v1 has no token-voting governance over the core, because there is nothing to govern: contracts are immutable and the guardian's three powers are the entire discretionary surface. Guardian actions follow the published runbooks; every cap change and its criteria are documented in the roadmap before it happens.
On the live curator platform the guarantee is
stronger. Curated baskets are guarded not by the Safe directly but by a
restricted CuratorGuardian contract whose only power is to raise the
supply cap (upward, never above maxSupplyCap). It has no setFeeRecipient
and no setMintPaused — those functions simply do not exist on it — so on a
curated basket the fee recipient is frozen forever and minting can never be
paused. Publishing is gated by a $WOOD burn rather
than any gatekeeper, and not even the protocol can redirect or choke a curated
basket's fee stream: the curator's payout is guaranteed by the code, not by
anyone's goodwill.
Across the whole curator platform the Safe holds exactly two bounded
levers: raising a curated basket's cap (upward-only, above), and the
global brake on the agentic layer — disabling a
settlement venue or a buyable asset, which freezes value movement without
ever touching redemption. It cannot touch funds or licenses. The
CuratorRegistry has no admin at all — the license burns are fixed
constants (10,000 $WOOD frozen / 25,000 $WOOD agentic). Everything else on
the platform is immutable.