Treasury Proposals Are Execution Policies, Not Polls

A treasury vote that passes but pays a recipient less than approved exposes how community funds are really allocated: executable instructions, rather than voter intent alone, determine the result. The responsible component is the proposal payload—the contract calls that select an asset, amount, route and destination after governance authorizes spending.

What happens after a treasury proposal passes?

The proposal normally moves from voting into a queue or timelock, then reaches an executor authorized to call the treasury. Follow one grant through that path: voters approve a stablecoin payment; the timelock holds it for the required delay; the executor withdraws the asset; and the final call transfers, swaps or bridges it to the recipient. Each additional action introduces another place where the delivered amount can diverge from the headline budget.

• Asset: the token actually held and released by the treasury.
• Route: a direct transfer, market swap or cross-chain bridge.
• Limits: minimum output, slippage ceiling and execution deadline.
• Authority: the address allowed to execute, cancel or retry the payment.

The calldata reveals the real allocation

Builders may describe a proposal as “100,000 stablecoins for development,” but the verifiable commitment is narrower: a target contract, function, token quantity and recipient address. If the treasury already holds the requested stablecoin, a direct transfer preserves the approved amount while the treasury separately pays network fees. If it holds another asset, a swap-sized budget makes the recipient absorb trading costs unless the proposal explicitly grosses up the input.

Cross-chain grants require even more precision. The proposal should identify the destination chain, receiving address, bridge route and minimum amount delivered. The mechanics discussed around Manta Bridge matter here because a bridge transaction is not equivalent to final receipt: settlement depends on the destination-side message and liquidity completing successfully.

How should voters compare treasury routes?

Compare recipient output under identical market conditions, not nominal proposal size. In a reproducible quote simulation, assume a treasury spends 100,000 units of stablecoin A. A direct same-chain transfer delivers 100,000 units of A. A swap into stablecoin B with a five-basis-point pool fee and eight basis points of price impact delivers roughly 99,870 units before any bridge charge. That 130-unit difference is execution cost, even though both proposal summaries can claim a 100,000-unit allocation.

The same test should be repeated at the executable block with the encoded slippage limit. Without a minimum-output check, searchers or ordinary market movement can worsen the fill between approval and execution. With a tight limit, the transaction may revert and delay the grant. One protects price; the other protects immediacy.

Better proposals make recipients whole

Treasury proposals improve execution when they define delivery rather than expenditure: exact recipient, destination asset, minimum received and a bounded deadline. That shifts routing costs back to the treasury and makes competing paths measurable. The trade-off is administrative complexity and possible re-execution; delegates and treasury operators bear that burden, while recipients avoid silently funding slippage and bridge fees.

Before voting, inspect the live proposal’s calldata, treasury balance, allowance, minimum output and destination address. After execution, trace every call through the swap or bridge and compare the final recipient balance with the amount voters believed they approved.