Why Token-Voting Governance Fails for Critical Relayer Parameters

Token-voting forces a choice between security, liveness, and decentralization. A malicious proposal to slash relay fees can pass with a 51% token majority, while a benign security upgrade can be stalled by voter apathy or whale cartels. This creates unpredictable failure states for critical infrastructure.

Voters optimize for their token's price, not the protocol's security. A whale holding $100M in stETH has zero incentive to vote for a fee increase that strengthens Lido relayers but reduces short-term yield. This misalignment is structural and unsolvable with token votes.

Governance is fundamentally too slow for operational security. A zero-day vulnerability in a relayer client requires an emergency patch in hours, not the 7-14 day voting cycles standard in DAOs like Arbitrum or Uniswap. This delay window is a gift to attackers.

Relayer parameters like fee curves and gas price oracles are prime targets for governance attacks. A coordinated whale can vote to set minimum fees to zero or manipulate price feeds, enabling cross-chain MEV extraction or draining protocol-owned liquidity, as theorized in Omnichain and LayerZero designs.

Token distribution does not map to technical competence. Expecting a retail UNI holder to correctly assess the safety of a Geth client upgrade for a rollup sequencer is a catastrophic design flaw. Critical parameters require credentialed, accountable experts, not a popularity contest.

Real-world failure occurred when MakerDAO's token holders voted to raise the USDC Debt Ceiling in its PSM during the 2023 banking crisis, directly exposing the protocol to $3.2B in depeg risk. This proves token governance actively introduces risk for critical financial parameters.

Token-holders are not infrastructure operators. Low participation on technical votes leads to stagnation or capture by a small, potentially misaligned cohort.

• <5% participation is common for parameter tweaks.
• Votes decided by <10 wallets controlling governance tokens.
• Creates risk of protocol ossification where critical updates are delayed.

A relayer's security (e.g., slashing conditions, bond size) conflicts with a token-holder's profit motive. Governance becomes a negotiation, not an optimization.

• Voters favor lower bonds to increase token liquidity, weakening security.
• Pressure to reduce fees compromises relayers' operational margins.
• Results in race-to-the-bottom on critical safety parameters.

Emergency parameter updates (e.g., after an oracle failure) require sub-DAO-cycle response times. Token voting is far too slow and lacks the technical context.

• 7-day voting delays are fatal during a live exploit.
• Voters lack real-time data on network congestion or relayer health.
• Forces protocols like Across to retain admin controls for rapid response.

Delegate parameter governance to a small, qualified, and accountable committee selected for expertise, not capital. This mirrors MakerDAO's ES model.

• Expert Stakeholders with skin-in-the-game (e.g., relayers, auditors).
• Faster iteration cycles for non-critical parameters.
• Transparent performance metrics enable removal for failure.

Encode governance into verifiable, on-chain performance metrics. Let the market dictate parameters, not votes. Inspired by EigenLayer's slashing conditions.

• Dynamic bond sizing based on relayed volume and error rates.
• Fee markets that auto-adjust based on supply/demand.
• Removes human latency and bias from real-time optimization.

A layered model where a nimble council handles emergencies, token governance sets broad direction, and code enforces limits. Adopted by Arbitrum and Optimism.

• Security Council can act in <24h with multisig safeguards.
• Token vote still controls treasury and major upgrades.
• Smart contract timelocks prevent unilateral abuse.