Forks, Sporks, Governance and Admin
The problem with the current Governance proposal
The Governance embedded contract proposal is trying to be too many things at once. As currently scoped, it’s a spork controller, a spork activator, and an embedded contract admin panel — all rolled into one. That means governance proposals can be submitted to create a spork, activate a spork, adjust liquidity settings, add bridge tokens, halt the bridge, and unhalt it.
Everything goes through a pillar vote.
That sounds principled until you hit an emergency. If the bridge needs to be halted right now, you have to submit a proposal and wait — either for pillars to engage, or in the worst case for the ratcheting mechanism to lower the voting threshold because they haven’t. We cannot run operational controls for live infrastructure on that timeline. Weeks or months is not an acceptable response time for a bridge incident.
Governance decisions and operational decisions are not the same thing. We need to treat them differently.
What Governance should actually do
One thing: manage sporks.
Sporks are consensus changes. They affect every node operator, they require a network fork to activate, and they absolutely warrant a pillar vote. The flow makes sense here — a pillar submits a proposal, voting runs, if approved a Spork ID is issued, a new znnd is compiled with that ID, and once enough operators have updated their binary a second vote activates it. The network forks, updated pillars continue, anyone who didnt update their node halts and needs to download the new znnd binary and re-sync to re-join the network.
That’s a genuine governance decision. That process should stay exactly as described. The Governance embedded should be scoped to just this — nothing else.
The admin problem
So if governance handles sporks, who controls the bridge halt, the liquidity settings, the plasma parameters?
Right now, a hardcoded admin address in each contract holds that power. Which means responsibility falls on one person. And it gets worse: the Dynamic Plasma admin is not the same as the bridge/liquidity admin. We have multiple admins across different contracts, some of whom we can’t reliably reach when needed. We’ve already seen what happens when the bridge admin is unavailable.
Single points of failure, spread across multiple contracts, with unclear lines of responsibility.
The proposal
Add multisig support to the network via a new multisig embedded contract, and move all contract admin controls to a multisig address — with signers being active, community-nominated members.
This does a few things at once. It removes the single point of failure across all embedded contracts. It means no one person holds the keys to bridge operations. It keeps response times short — a multisig can act in hours, not weeks. And it’s worth being clear: none of these admin methods can access embedded contract funds. These are purely operational controls — updating settings, halting, unhalting, adjusting parameters. The multisig is not a treasury.
A bonus: we can delete the guardians
Moving admin to a multisig has a less obvious benefit — it lets us remove the guardian logic from the bridge and liquidity contracts entirely.
Does anyone actually understand what the guardians are for? How they can change an administrator? Do we know who they are, or whether they know they are one? The guardian system was presumably added as a safety valve around the single-admin model, but with a multisig the safety is built into the structure itself. The guardians become redundant, and removing them simplifies contracts that are already complex enough.
Summary
-
Scope the Governance embedded to spork issuance and activation only — remove everything else
-
Introduce a new multisig embedded contract
-
Move all current and future embedded contract admin controls to the multisig, with community-nominated signers
-
Remove the guardian pattern from the bridge and liquidity contracts as a consequence
Interested to hear whether others see the governance/operational split the same way, and whether there’s appetite for the multisig approach or alternative ideas for handling contract admin.
