Where the money lands
In one address, written into every Olympia client and the same for all of them. As each block is finalized the client credits that address with the block’s base fee revenue. There is no transaction, no sender and no code running at the far end.
Two contracts sit behind that, and they do different jobs. The one consensus credits is the Olympia Sovereignty Vault, and it is deliberately almost nothing. Around thirty lines. No owner, no role, no setter, no parameter to tune, nothing to configure and therefore nothing to misconfigure. Whatever it receives it forwards to a single address fixed when it was built. That address is the Olympia Treasury, and the Treasury is what actually holds the money.
- Where funds landThe Olympia Sovereignty Vault
- The address consensus credits, specified by ECIP-1112. It keeps nothing: whatever arrives is forwarded, unchanged, to one address fixed when the contract was built. It is the only contract in the suite that cannot be replaced.
- Where funds liveThe Olympia Treasury
- Where the money sits while governance decides what to do with it, and the only place a payment leaves from. Specified by ECIP-1113, it is a stock timelock chosen off the shelf rather than written for this, and governance can replace it without a fork.
The hand-off needs someone to trigger it
Moving a balance from the Vault to the Treasury takes one call, and anyone at all may make it. Nothing pays them to, so at low revenue the gas can cost more than the amount moved and a balance may sit there for a while. That is inconvenience rather than risk: the caller chooses when the money moves and never where, because the destination cannot be changed by anyone. A disbursement that needs the funds simply leads with that call.
Nothing is predicted
No address is worked out in advance. The contracts are deployed by ordinary transactions, the real deployed address is published, and only then is it written into the clients. The fork commits to code that already exists on-chain and that anyone can read first, rather than asking the network to trust a deployment that has not happened yet.
Exactly one contract is permanent
That single boundary is the architecture. Consensus has to name something in place of the burn, and whatever it names cannot be changed again without a hard fork, so the design puts as little as it can get away with on the permanent side of that line and leaves everything else on the other. The question it answers is not what a treasury contract should look like. It is what the smallest object the network is willing to make permanent could be.
The Olympia Sovereignty Vault
Around thirty lines of code with no owner, no role, no setter and no parameter to tune. It holds one address, fixed when it is built, and it forwards everything it receives there. This is the address consensus credits, so changing it is a hard fork.
Everything below it
The Olympia Treasury that holds the money, the Governor that spends it, the voting model, the sanctions oracle. Each of them is changed by an ordinary proposal, and none of it needs a fork or the agreement of anyone running a node.
The Treasury is replaceable, with one qualification worth stating
What the fork makes unchangeable is where new revenue lands, not who is allowed to spend it. The Vault’s destination is fixed at construction, so the Treasury standing at that address keeps receiving whatever arrives next. Governance can still deploy a successor and move the whole balance across by ordinary proposal, because the Treasury forwards arbitrary calls, and everything that accrues afterward can be moved the same way, indefinitely.
What never ends is the forwarding. So replacing the Treasury is a governance program with a step that repeats, rather than one vote that finishes the job, and no part of it needs a hard fork.
This is what the extra contract buys. Crediting the Treasury from consensus directly would have removed a hop and made the Treasury itself the permanent object, so replacing it would have taken a hard fork and every guarantee would have had to be proved about a general purpose contract with a permissions table instead of about thirty lines with none.
Who owns it
No company, no foundation and no individual. It is not a multisig and there is no key that opens it. One account is able to tell the Treasury to pay, and that account is the Governor, which does nothing except carry out proposals that were voted through, queued where anyone could see them and held for a fixed delay before they moved.
There is an administrator, briefly, and then there is not. Setting the contracts up takes a short sequence, and the account running it holds an administrative role between creating the Treasury and wiring the Governor to it. It gives that role up in the same sequence, before the Vault exists and before any address is published. Throughout that window the Treasury holds nothing, no revenue has ever been credited, and the network has not forked.
What holds this in place, said plainly. The Treasury administers its own permissions, which means governance can change its own rules through exactly the same public process it uses for anything else. The permissions are set at deployment and published so that anyone can read them back off the chain and confirm for themselves that the Governor is the only account able to release funds and that no administrator remains.
So what stands between a hostile proposal and the money is not a clever contract. It is the ordinary machinery: a proposal has to win a vote, it sits in a public queue for a delay that everybody can watch, and a counter-proposal can cancel it before it executes. Anyone claiming the arrangement enforces itself is describing something other than this.
What the Treasury does not do
Most of what a reader expects a treasury to do, it does not do, and the omissions are the design rather than gaps in it.
It does not invest
The balance is not lent, staked, wrapped or put to work. It sits until a proposal moves it.
It does not allocate
Nothing splits the balance between purposes by formula. Every payment is a proposal that passed, one at a time.
It does not choose recipients
The contract has no opinion about who deserves anything. It executes what governance already decided, and reverts if it cannot.
It does not keep its own books
The Vault counts nothing. Consensus credits it by writing to its balance without running any code, so a contract totting up its own deposits would total zero and the money would never leave. Its balance is the only record, deliberately.
There is no minimum amount before the Vault can forward, either. On a chain whose revenue starts small, a threshold is a way to strand funds below it, which costs more than the nuisance a threshold removes.
Watching the balance
All of it is public, and none of it requires anyone’s cooperation to see. Two addresses are worth watching rather than one: revenue lands at the Vault and is spent from the Treasury, so a balance sitting at the first simply has not been forwarded yet.
Read it from the chain rather than from anybody’s dashboard. Both balances, every credit into the Vault, every forwarding call and every payment the Treasury makes are ordinary chain state, so a block explorer answers all of it and no operator sits between the question and the answer.
What to check, and where
The architecture is six contracts and the boundary between the first two is the whole of it. Which contract does what, and which ECIP specifies each, is set out on the home page; the balances and the transaction history behind them are on the block explorer for whichever chain you are asking about.
Four things are published ahead of the activation block so that none of this has to be taken on trust: the Vault’s deployed address and the code at it, the address it was built to forward to, the full permissions table for the Treasury, and the verified source of the Governor and the membership token. Publishing the permissions is the part that matters most. It is what lets anyone confirm from chain state, without trusting whoever deployed it, that one account can release funds and no administrator is left.