Security and trust · Ostra Agent docs

A post-quantum claim is only as strong as the weakest key that can move funds or change code. This page lists every key in Ostra that can do anything, what each one can and cannot do, and the limits Ostra states openly.

7.1In short#

No secp256k1 key in Ostra can take funds held in a vault or in the shielded pool. They move only with WOTS one-time signatures, checked on chain. The only exposure is money in flight, each deposit while it moves into the pool and the unused balance of each payment channel, from which only that channel's receiver can be paid, and guardians an owner makes ordinary wallets, so guardians should be vaults too.
The code of the vaults and of the pool can change only through OstraUpgradeOwner: a WOTS-keyed contract whose every call waits 72 hours in public before anyone may run it.
The launchpad contracts are not upgradeable. Their owner, still an ordinary account, can only collect the protocol's fees.
There has been no external audit yet. The pool's limits are deliberately small.

7.2Every key with a power#

Keys that hold funds or change code: WOTS#

Key	Can	Cannot
A vault’s key	Sign one spend of its vault, then it is replaced	Sign again once rotated
A creator vault’s key	Change its pools’ rules in traders’ favour; set creator-split shares; run airdrop rounds	Move a rule against traders
Shield approval and leaf keys	Approve one batch state; move one leaf to the destination it signs	Anything else
Upgrade owner key (`0x5553…6E5e`)	Schedule any call, run 72 hours later by anyone. What it owns is the two beacons: it can upgrade them, hand them to another owner, or give them up for good	Act without 72 hours of public notice, or after the 14-day grace period
A vault’s guardians, when they are vaults (optional)	Together, at the owner’s threshold, replace the vault’s key after the owner’s delay of 36 hours to 14 days	Take a vault whose owner spends during the delay

Keys that run on secp256k1#

Every transaction on Robinhood Chain, as on any EVM chain today, is signed with secp256k1 by the account that sends it; no application can change that. What Ostra changes is what a sender decides. The relayer, the aggregator and the keeper carry calls that WOTS keys, or a vault's own crank, authorized, so a broken sender key can delay a call or refuse to send it, but never alter or forge one. The worst case is the most each key could cost if a quantum computer, or a thief, had it.

Key	Can	Worst case if broken
Relayer	Send what agents signed, at a price the agent checks; it sees which signed calls come from one client. A signed spend has no expiry, so it could hold a swap and send it later, at a price still within the slippage the agent signed (1% by default)	Its own ETH for gas. Calls wait, or the agent sends them with its own fee payer; a signed operation cannot be changed server.ts:1-3
Aggregator	Create, fill, seal and abandon batches	Its own ETH for gas. Batches stall, and a deposit that never seals goes back to its vault after 48 hours aggregator.ts:1-29 OstraPool.sol:304-314
Keeper fee payer, and a vault’s crank key (optional)	Pay the gas of settlements; settle the vault’s payment channels	Their own ETH for gas. A crank could refund a buyer’s unclaimed escrow to the buyer before claiming it, so its seller loses vouchers not yet claimed; nothing held in the vault
Payment-channel voucher keys	Pay within one channel’s deposit, which the vault’s owner sets: 1 USDG by default	The unused balance of that channel, paid only to that channel’s own receiver config.ts:35-39
A shield depositor key	Hold one deposit from the vault’s transfer until the deposit lands	That one deposit, currently 250 USDG at most, until it lands; a deposit the pool has no room for is refused before the vault sends anything shield.ts:4-37
Launchpad owner (`0x6569…50A2`)	Collect launch fees, the operator’s share and the buyback share; hand its role to another account or give it up	The protocol’s own fee income. It cannot pause, change fees or rules, mint, or touch liquidity, payouts or vaults
Pool init authority and treasury (same account)	Raise the pool’s deposit limits; receive the 0.30% fee when a batch seals	Higher limits and the fee income. It cannot lower the limits, change the fee or the treasury, or move funds
A vault’s guardians, when they are ordinary wallets	The same as guardians that are vaults	The vault, if its owner neither spends nor cancels during the recovery delay. Guardians that are vaults remove this

The pool's fee and treasury are fixed for good and its limits only go up OstraPool.sol:201-209. The launchpad owner's functions are listed on the hook page. One account was made the launchpad owner deploy.ts:216, the pool's init authority and its treasury deploy.ts:87 at deployment; the beacons it also owned then were handed to OstraUpgradeOwner.

7.3The upgrade owner#

An upgrade of the vault beacon changes the code of every vault at once. If that power sat behind an ECDSA key, a quantum computer, or anyone who stole that key, could replace the vaults' code and take their funds without touching a single WOTS key. So both beacons are owned by OstraUpgradeOwner 0x5553…6E5e, deployed and handed both beacons on 19 October 2026 OstraUpgradeOwner.sol:6-28.

Its rules#

Every call needs a WOTS signature from its current key over "OSTRA/OWNER/EVM/v1" ‖ chainid ‖ owner ‖ nonce ‖ action ‖ payload ‖ nextKeyRoot, and the key rotates on each one, as a vault's does OstraUpgradeOwner.sol:78-84.
schedule records a target and the hash of its calldata, and publishes the full calldata in CallScheduled. It may run 72 hours later, and only until 14 days after that OstraUpgradeOwner.sol:91-101.
execute is open to anyone within that window, with exactly the scheduled calldata OstraUpgradeOwner.sol:111-123. A call that fails stays scheduled.
cancel is signed too, and a valid cancel never reverts: if the call already ran, it only rotates the key, so a signed cancel can never leave a key half-used OstraUpgradeOwner.sol:103-109.
The delay is fixed in the contract at 72 hours (259,200 seconds), and could only ever have been set between 1 and 30 days OstraUpgradeOwner.sol:34-46.

Giving up the upgrade right for good is a scheduled call like any other: renounceOwnership on a beacon, after the same 72 hours.

7.4Watching for an upgrade#

Anyone can check, at any time, that nothing is waiting:

every scheduled call emits CallScheduled(id, target, data, eta) on the owner contract, with the full calldata and the earliest time it can run;
getCall(id) shows a call's target, time and calldata hash; ids are the owner's nonce at signing;
the vault beacon and the pool beacon emit Upgraded when a call runs, and owner() on each returns the owner contract.

An upgrade's calldata names the new implementation, so its source can be checked on Sourcify while the call waits. Seventy-two hours is enough for a vault owner to see an upgrade, read its code and withdraw before it can run.

7.5Audit and testing#

What exists instead, all in the repository:

Verified source. Every Ostra contract is verified on Sourcify: the published source compiles to the exact code on chain. See contracts.
Tests against mainnet. The vault, pool, launchpad and upgrade-owner tests run on a fork of Robinhood Chain mainnet, against the real USDG, Uniswap v4 PoolManager, Universal Router and stock tokens, not mocks Vault.fork.t.sol:79. The WOTS, LtHash and fee libraries also have unit tests.
Shared vectors. The TypeScript signer and the Solidity verifier are checked against the same signatures Wots.t.sol:32-40.
Tested scripts. The deploy and upgrade scripts each have a fork test that runs them as on mainnet.

7.6Known limits#

Collected from the other pages, so that none is buried:

The launchpad owner, the pool's init authority and its treasury are one secp256k1 account. Their powers are limited to collecting fees and raising limits.
The relayer, like the aggregator, can see which deposits, leaves and private vaults belong to one client.
A signed vault spend has no expiry, so that it is never signed twice: the relayer could hold a signed swap and send it later, at a price still within the slippage the agent signed.
If the pool fills up between a vault's transfer and its deposit, the deposit waits on its depositor key until there is room.
A machine restored from the seed relies on the relayer's escrow to know which keys already signed.
Guardians that are ordinary wallets make a vault's recovery depend on elliptic-curve keys.
The aggregator knows which leaves belong to which deposit until a batch seals, and deleting that is policy, not cryptography.
The minimum of 8 deposits per batch is enforced by the aggregator, not the contract.
The buyback share is claimed by the owner; buying and burning $OSTRA with it happens off chain.
Graduation opens outside liquidity only once the anti-farmer period, up to 365 days, has also ended.
A launch made outside the Ostra tools may use any contract as its creator vault, and may turn the circuit breaker off.
NYSE holidays are encoded up to the end of 2028.
Robinhood Chain, USDG and stock tokens are run by their issuers and operators, with their own keys and controls.