the security council
Proof systems weren't just about correctness. This is an observation that sounds obvious in retrospect and was genuinely underappreciated while proof systems were being shipped. When a fraud proof window governs withdrawals from a rollup, the keys to the bridge belong to the protocol, not the team. Nobody personally owns custody of depositor funds. The multisig that can upgrade the contracts has limited power because the withdrawal mechanism has its own independent guarantee. The legal and liability architecture of a rollup changes substantially when the proof system is in place. Without one, someone holds custody. That someone is a person or a set of people, and the implications of that are not purely technical.
For Signet, the deposit mechanism is Passage. Signet USD exists on L2. The filler market is what enables cross-chain liquidity to flow: fillers provide USD on the Signet side, users provide ETH on the Ethereum side, and the atomic settlement mechanism ensures both sides of the exchange happen in the same block. But the filler market is competitive and sometimes thin. When no fillers are filling exit orders — when the market is illiquid, or when a filler has an inventory problem, or when conditions are unusual — users with USD on Signet need a path out that doesn't depend on a filler appearing. That path is the admin withdrawal route through Passage. The entity that holds the admin keys to Passage is the security council.
Designing the council required holding two questions that don't resolve cleanly against each other. What do you want them to do: sign rebalancing transactions when the filler market runs dry, govern contract upgrades, respond to emergencies, maintain the liveness of the withdrawal mechanism. What can you hold them accountable for: almost nothing. The council members are volunteer or lightly compensated. There is no legal entity, no formal liability structure, no enforcement mechanism if they go dark at a critical moment. The security council is the point in the system where technical guarantees end and human reliability begins. Designing it well means being honest about what that means.
The liveness problem is the one that concentrates the mind. If the filler market is empty and the council is unresponsive, users have USD on Signet that they cannot exit. The council doesn't need to be malicious for this to be a problem — they just need to be unavailable, or slow, or uncertain about what they're being asked to sign. The operational discipline required from a council with no formal accountability is high. The parallel to Ethereum's early multisig governance is not flattering: the history is full of moments where the humans holding keys were slower, less coordinated, or more conflicted than the protocol assumed they would be. What distinguishes a council that functions from one that doesn't is almost entirely culture and selection criteria — neither of which is a technical property.
The business model question for council members is real even if it sounds strange. They are providing a service — liveness insurance for user exits — that has genuine economic value. They are compensated, if at all, in a way that does not reflect that value. The gap between the service's importance and the council member's incentive to remain engaged and responsive is a design problem that most rollup teams paper over with the assumption that council members will behave like civic-minded volunteers. Sometimes they do. The question worth asking is what the council looks like two years into a market downturn when chain activity is low and the council seat has stopped being interesting. Designing for that scenario, rather than assuming away from it, is the harder and more honest version of the problem.