Why the check exists
People who take part in Ethereum Classic are subject to sanctions law wherever they live, and no design choice inside a protocol changes that. Olympia pays money to named recipients, and the people voting those payments through are the ones the obligation attaches to. So the network needs a real working control rather than a symbolic one.
The obvious counterargument does not reach this design. A US federal appeals court held in 2024 that an immutable smart contract is not the kind of property that can be sanctioned, and the sanction on the contract at issue was lifted the following March. That reasoning turns on the immutability of the specific contract, and everything Olympia governs is replaceable by ordinary proposal. A separate case established that a group governing a protocol by vote can itself be treated as an entity carrying obligations. Both point the same way.
It cannot touch the audited code
The Governor and the Treasury are widely reviewed off-the-shelf contracts, and threading compliance logic through their internals would throw that away. The check hangs off an extension point those contracts publish for the purpose, so nothing audited is edited.
It cannot hold up the deployment
The list is a separate contract the Treasury attaches later, rather than something baked into the others when they are built. It can be designed, audited and swapped on its own schedule, including after the fork, and replacing it never means replacing anything else.
It has to fail shut, not open
Until a list is attached, the Treasury cannot pay anybody at all. A missing or broken list blocks payments rather than waving them through, so the worst case is that nothing works rather than that everything does unchecked.
The check that binds
It sits inside the Governor and runs at the last possible moment, after the vote, after the queue, in the same transaction that releases the money. It reads every address the operation is directed at, and if any of them is on the list the whole thing reverts and nothing moves.
There is no way around it, and the reason is structural rather than vigilant. Exactly one account is permitted to tell the Treasury to pay, and the check lives inside that account. A proposal that skipped the registry still meets it. A proposal written by a core contributor meets it. There is no second executor, no administrator and no emergency path, so there is no route that reaches the money without passing through here.
It also runs at release rather than at approval, which is the difference that matters in practice. Somebody who was clear when the proposal passed may be designated during the weeks of voting and delay that follow, and checking only at the start would pay them anyway.
The general-purpose escape hatch is welded shut
The standard Governor ships with a recovery function that pays anything to anyone, meant for retrieving tokens sent to it by mistake. Left in place, a single proposal naming the Governor itself would pass the screen and then pay an unscreened address. Olympia overrides it to fail. Any replacement Governor has to carry that override too, or the check above it guarantees nothing.
Two addresses are skipped, deliberately
The Governor and the Treasury themselves. An operation aimed at either is the governance system configuring itself rather than paying anyone. It also removes a way to lose everything: if the list ever named the Governor, every proposal that could fix it would revert, and the Treasury would be permanently unspendable with no fork able to repair it. The contract additionally refuses to accept a list that flags either address.
What the check sees, stated as a condition rather than a promise. For an ordinary payment, the address being screened is the address the money settles at, and there the screen is exact. That holds only while that address carries no code. A contract routes value onward by its own logic, and an ordinary account can carry a delegation that makes it behave like one, so neither is exactly screened and neither may be described that way. The saving grace is that the distinction is checkable rather than a matter of trust: a delegation is itself code, so the check can see that it is there.
One case is deliberately not claimed against. An address that holds no code when it is paid can take on a delegation in a later block and forward the money afterward. Nothing here prevents that, and the guarantee is over the state at the moment of release, which is when the obligation attaches.
The other screens, and what they are worth
There are four checkpoints in the specification, and they are not equally strong. Reading them as four layers of the same defense is the mistake this section exists to prevent.
- 1When a proposal is submittedAdvisory
The proposal registry, against the named recipient
Skippable by design, because a proposal can be put straight to the Governor instead. Worth having so voters do not spend a fortnight on something that cannot execute, and nothing rests on it.
- 2When the money leavesBinding
The Governor, against every outward address in the operation
Unavoidable. One account is able to tell the Treasury to pay, and this check runs inside that account, so every release passes through here whatever route its proposal took.
- 3Every time a stream pays outOnward custody
The milestone-gated streaming contract
Binding inside that contract, and satisfied when it is deployed carrying the rule and an audit confirms it. Written as a property of the contract rather than a list of its functions, because an earlier list missed a real path.
- 4Every admission and every redemptionOnward custody
A Affiliated DAO's own vault and promotion path
Same condition, and the reference is held under that Affiliated DAO's own governance rather than Olympia's, so an Affiliated DAO applying a different sanctions list has to disclose that it is doing so.
Coverage stops at the Treasury path. The first two checkpoints secure the money on its way out of the Treasury and nothing beyond that, and no claim here reaches further. The other two cover what happens to funds afterward, inside contracts that take custody once the Treasury has released, and each is satisfied when its contract is deployed carrying the rule and an audit confirms it. Anyone assessing the position should establish from the chain which of the four are actually running, rather than reading a four-row table as a description of what exists.
The submission screen looks like a second barrier and is not one. Anyone with enough voting power can put a proposal straight to the Governor without touching the registry, so treating that screen as redundant cover overstates the control by exactly what a single direct proposal removes. It is also mistimed: submission comes before the voting delay, the voting period and the queue, so somebody designated during that stretch would pass it and be paid anyway. That is the whole reason the binding check lives at the other end.
Onward custody is the requirement it is easiest to miss. Once the Treasury has paid a streaming contract, its guarantee is spent: that contract now holds the funds and releases them in tranches for months, against an address that can be designated at any point in between. A contract that takes custody of Treasury money inherits the obligation along with it, and satisfying the check at the moment the Treasury paid is not satisfying it.
One thing is deliberately not screened: money returning to the Treasury. Reclaiming an unspent remainder is not a payment to a recipient, and screening it would mean that a list which ever named the Treasury would strand every reclaimable balance where governance could not reach it.
Who keeps the list
Every checkpoint consults a list, and somebody maintains that list. This is the one point of central control the rest of the design cannot remove, and it is disclosed rather than glossed. The rest of Olympia has no administrator; this part has one, with limits on what it can do.
Editing the list and deciding who may edit it are separated on purpose. A new designation has to be reflected in hours, so routing every edit through a full governance cycle would produce a list that is stale rather than safe. Granting or withdrawing the ability to edit is not urgent, so that goes through the same proposal process as a Treasury payment. Handing over administrative control takes two steps and at least forty-eight hours, and the role cannot be abandoned in a way that leaves it permanently unassignable.
A stale list looks exactly like a clean one
Failing shut catches a missing list, and it cannot catch a list that simply stopped being updated: an address designated yesterday and an address never designated both come back the same way. So the list publishes when it was last updated, on-chain, and whoever operates it has to disclose the source, the arrangement for polling it, and the lag actually observed between the two.
The dangerous error leaves no trace
An address wrongly added blocks a payment, which is visible immediately and corrected on the next update. An address that should have been added and was not lets a payment through and leaves nothing behind. Failing shut does not defend that direction, which is why the operating detail is published rather than assumed.
Being wrongly listed costs a payment, never the money. No incorrect flag can send funds somewhere they should not go; it stops them going anywhere. The blast radius is wider than one payment, though, since a flagged stream beneficiary stalls every remaining instalment until the list is corrected. And there is no appeals process, because none is needed: the check is asked fresh every single time, so an address removed from a list is payable again on the next attempt with nothing to unwind.
The interface is deliberately the one already in general use elsewhere, so any conforming list can be adopted without changing a contract, and the list may be run as a mirror of one published on another network. A mirror has to say which list it mirrors and must not be presented as equivalent to it.
What the check does not reach
The rule reaches the contracts Olympia deploys. It does not reach the third-party contracts underneath them, and pretending otherwise would be worse than the gap.
Stated plainly: a sanctioned address can trade in a prediction market and redeem its own collateral, and no Olympia contract can stop it. The collateral in those markets is held by a general-purpose contract nobody here deployed, and it was posted by the traders who own it. Claiming back your own money from a contract Olympia is not part of leaves nothing for Olympia to check. The same is true of a swap in a liquidity pool.
What is actually guaranteed
That no Treasury money, and no money held by a contract Olympia deployed, reaches a sanctioned recipient. It is checked at the moment of every release, whatever route the authorizing proposal took to get there.
What is not
Anything happening in a permissionless contract Olympia does not control. An Affiliated DAO wanting broader cover has to gate the edge it does control, which is admission to its own vault, because the market itself is not Olympia’s to gate.
A sanctioned address can still ask. It cannot be paid. Putting a proposal forward is open to anyone, so nothing prevents one being authored from a designated address. The guarantee is about receiving money, not about taking part, and it must not be described as covering both.
The check screens whoever receives value, and never a voter. There is no identity requirement anywhere in Olympia governance and none may be imposed. Identity checks appear in exactly one place, the optional legal wrapper that converts an already-approved payment to cash, and that is a property of the wrapper rather than of holding a vote.
Blocking addresses at the consensus layer was considered and rejected. It would take a hard fork, and it would stop a designated address transacting on Ethereum Classic at all, which is far wider than the obligation Olympia is answering. The markets this section is drawing a boundary around.