How to Use Delegated Voting in Protocol Governance

Gideon Elliott — Wed, 09 Sep 2026 22:02:09 +0000

Delegated voting shapes protocol decisions by turning scattered token ownership into an organized voting mandate.

The broader Universal Bridge question sits beside this one in the Universal Bridge context.

That distinction matters because a token holder can keep economic ownership while assigning the work of governance to someone who reads proposals, checks technical consequences, and votes consistently. The delegate receives voting power, not custody of the tokens. The holder can usually change or revoke that delegation, subject to the protocol’s snapshot rules.

What delegated voting changes

Delegation changes who spends the time required to make a decision. Without it, voting power is spread across holders who may miss a proposal, lack the context to assess it, or decide that the gas fee is not worth paying. With it, a smaller group can study upgrades, fee changes, validator settings, treasury spending, or security parameters closely enough to form a position.

That concentration is useful only when the delegate is accountable. In deBridge Protocol, for example, governance can affect practical settings such as fees, supported chains, validator elections, and validator payouts. In Wormhole Protocol, MultiGov coordinates proposals and votes across chains, so a delegate may need to understand both the proposal and how its voting power is aggregated. Hyperlane Protocol presents a different technical surface, with modular security components whose configuration can change the risk and operating cost of an application.

The common point is that a governance vote can alter the machinery users depend on. Delegated voting turns attention into a scarce resource that someone explicitly commits to supplying.

How to use it from start to finish

Read the proposal, not just the delegate’s label. Check what contract, parameter, chain, or budget changes, and whether the proposal has a delay before execution.
Compare the delegate’s record. Look for voting participation, written rationales, conflicts of interest, and whether past votes match the principles they claim to follow.
Delegate before the voting snapshot. A delegation made after voting power is recorded may not count for that proposal. Confirm the relevant chain, governance portal, and wallet transaction before signing.
Monitor and reassess. Delegation is not a permanent endorsement. Review how the delegate handles contentious votes, then redelegate or vote directly when the stakes justify your attention.

The direct cost is usually a network transaction and the time spent reviewing the delegate. The larger cost is opportunity: once voting power is delegated, the holder may stop tracking decisions closely. That is efficient for routine governance, but dangerous when a proposal changes security assumptions or grants broad upgrade authority.

Why the choice affects outcomes

Delegated voting does not make governance automatically wiser. It makes participation more continuous. A delegate who follows every proposal can notice a flawed implementation, ask for a parameter change, or oppose a rushed upgrade when most token holders are inactive. Conversely, a popular delegate can accumulate enough voting power to narrow debate or make a decision appear more representative than it is.

The practical verdict is straightforward: delegate when the issue requires more time than you can reliably give, but treat the delegate as an ongoing decision-maker, not a set-and-forget setting. Protocol decisions improve when voting power follows informed attention, and they weaken when concentration replaces scrutiny.

What Gas Fees Actually Pay For

Gideon Elliott — Wed, 09 Sep 2026 18:38:45 +0000

Gas fees are the price you pay to have a transaction executed, stored, and confirmed by every node in the network.

That is the whole settlement. When you sign a transaction in MetaMask Wallet, the total you spend is not a random markup. It is the product of two numbers: gas used, which is a fixed protocol-determined count of computation units, and gas price, which is a market you participate in. The trick of Ethereum's design is that both numbers are public. You can see exactly what the network charged and why.

What a gas unit is

The Ethereum protocol assigns a cost to every operation. Adding two numbers costs 3 gas. Reading a storage slot that is already warm costs 100 gas. Setting a storage value from zero to non-zero costs 20,000 gas. A plain ETH transfer costs 21,000 gas. These numbers are calibrated against the real CPU, memory, and disk cost of each operation on every machine running the chain. The point is to make the work finite and measurable. If an operation were free, an attacker could fill a block with useless loops and stall the entire network.

What the fee actually pays for

Your gas payment buys three services. The first is execution: validators run your code, and the priority fee you attach is the incentive for them to choose your transaction from a queue. The second is state change: your result is written into the global state trie that every node keeps, which costs disk space and memory forever. The third is finality: the block containing your transaction becomes part of the canonical chain, and every block that follows builds on it.

The base fee portion of your payment is burned. No one receives it. EIP-1559 created this burn so that block space behaves like a properly priced commodity rather than a subsidy that collapses under spam. Validators only receive the priority fee you add. That is why a transaction with a base fee of 10 gwei costs something different from one with a base fee of 50 gwei — the base fee tracks demand, and the burn removes tokens from supply.

The Layer 2 difference

On a rollup like Manta Network, your fee buys the same three services, but it also buys a fourth: a slot in a batch. Your transaction is processed by a sequencer, bundled with thousands of others, and the whole batch is published to Ethereum. On a ZK rollup, you also pay for a proof — a cryptographic assertion that the entire batch is valid — which a contract on Ethereum verifies. The line item you see in your wallet is therefore not a single payment but several: execution on the rollup, data availability on the DA layer, proof verification on L1, and a small sequencer premium.

This is why L2 fees scale the way they do. The cost of publishing the batch is amortised across all users in the batch. For a typical transfer on Manta, your share of the DA cost might be a fraction of a cent. But the proof verification cost is fixed per batch, not per transaction, so it grows with the number of batches, not the number of users. This is the key economic fact of rollup architecture: costs are dominated by fixed overheads, not by marginal transaction work.

The failed transaction you still pay for

The edge case most guides skip is the failed transaction. If your transaction reverts, it still executed every opcode up to the revert point, and you still pay for that computation. The base fee is burned exactly as if it had succeeded. MetaMask Wallet shows you an estimated fee before you sign, but that estimate only covers the gas price; it does not tell you whether the operation will succeed. A real example: you set a priority fee too low, the transaction sits in the mempool, you assume it failed and resubmit with a higher fee. Both transactions get confirmed. You pay both times.

Bridging adds another layer

Moving assets across chains brings a second fee stack. When you send tokens from Ethereum to Manta via Celer Network's bridge, you pay gas on the source chain to lock the tokens in the bridge contract. Celer's relayers then observe the lock event and mint the corresponding tokens on Manta. That mint is a separate transaction on the destination chain, with its own base fee and priority fee. Some bridges also add a protocol fee on top. So a cross-chain transfer is not one cost but two or three, appearing in different parts of your wallet.

What changed by 2026

The biggest change in recent years was EIP-4844, which went live in March 2024. Rollups stopped posting call data to Ethereum and started posting blobs — a separate data market with far lower prices. The effect was a dramatic drop in L2 fees. By 2026, the dominant cost on most rollups is no longer data; it is proof generation and L1 proof verification. On Manta, that means your fee today mostly pays for the prover and the L1 contract that checks its work, not for the bytes of your transaction being stored on Ethereum.

That distinction matters when you are deciding where to build. L1 fees punish every byte of calldata. Rollup fees punish fixed costs per batch. The same dapp will have a very different cost profile on each.

If you want to see the mechanics applied to a real network,

Manta Bridge's fee guide

walks through the same math in detail.

DEV Community: Gideon Elliott