A DAO vote that passes does not do anything. Somebody still has to send the transaction that carries the decision out, and that transaction costs money. On almost every token DAO in production, nobody has decided who that somebody is, nobody has priced the work, and the cost appears in no budget. This page sets out what the default actually is in deployed governance code, what the same job costs when a DAO buys it from an automation vendor instead, and why an unowned recurring cost is a governance problem rather than an accounting footnote.

The default: permissionless and caller-paid

The two contracts that most token DAOs inherit their governance from agree on this, and both are explicit about it in source.

OpenZeppelin's Governor declares the final step as function execute(address[] memory targets, uint256[] memory values, bytes[] memory calldatas, bytes32 descriptionHash) public payable virtual returns (uint256). It is public, it is payable, and it carries no access-control modifier: any address may call it once the proposal is in a succeeded state (Governor.sol).

Compound's GovernorBravoDelegate, the lineage behind a large share of the DeFi DAOs that followed, declares function execute(uint proposalId) external payable, and its only guard is a state check: require(state(proposalId) == ProposalState.Queued). There is no check on who the caller is (GovernorBravoDelegate.sol).

Permissionless execution is a deliberate and good design. It means a passed proposal cannot be strangled by an executor who declines to act, which is a real failure mode for any design that hands the final step to a named party. But permissionless is not the same as free. Because the function is a normal transaction, the caller pays the gas, and because there is no reimbursement path in either contract, the caller absorbs it. The DAO gets its decision carried out and never records what carrying it out cost, or who bore it.

The size of the bill is not trivial for the proposals that matter most. Execution runs every call in the proposal's batch, through a timelock in the Bravo design (the proposal lifecycle sets out that queue-then-execute sequence), so a proposal that touches several contracts pays for several calls in one transaction. The heavier the decision, the heavier the transaction, and the more it costs whoever happens to click the button.

What the same work costs when you buy it

The clearest way to see that execution is real work with a real price is to look at what the automation market charges for it. These are the vendors a DAO hires when it decides not to rely on a volunteer.

Chainlink Automation prices an "upkeep" as the gas the transaction actually consumed, plus a node-operator percentage premium that varies by network, plus a fixed 80,000 gas of overhead for the call from the node into the registry. Chainlink's own worked example is a Polygon mainnet upkeep that used 110,051 gas at a gas price of 182,723,799,380 wei, with the node premium on Polygon at 70% at the time, producing a fee of 0.008077 LINK (Automation billing and costs). Two structural details matter more than the number. The upkeep must be pre-funded and hold a running balance above a minimum sized for a gas spike, or the network simply stops performing it. And withdrawing that balance requires cancelling the upkeep, with a 0.1 LINK cancellation fee charged to any upkeep that never spent 0.1 LINK over its lifetime, explicitly to deter registrations that never perform.

Chainlink's documentation index now steers new integrations away from Automation and toward its Runtime Environment, instructing readers to "prefer CRE for new multi-step, offchain, or automation workflows unless another product is explicitly required", and to consider Automation only where a task requires it or an existing integration is being maintained (docs.chain.link documentation index). A DAO that wired its execution into a vendor product is holding a dependency whose vendor is redirecting new work elsewhere, which is the pattern set out in DAO tooling discontinuity.

Gelato prices the same category as a subscription in compute units rather than per transaction: a free tier at 10M units, Pro at $99 per month for 20M, Growth at $399 per month for 100M, and autoscaling beyond the plan at $40 per 1M compute units (Gelato pricing plans). The shape is the interesting part. Gas is a per-event cost; a subscription is a standing one. A DAO that buys execution as a subscription pays in the months it passes nothing, which is precisely the cost profile a governance budget is built to hold, and precisely the line no surveyed DAO has.

Both vendors are pricing the same thing the Governor contracts hand to a volunteer for nothing: somebody watches for a condition, and when it is met, somebody sends and pays for a transaction.

The other answer: stop making it a proposal

A second response to the same pressure is not to price execution but to remove most of it. In January 2026 Aragon set out a direction it calls policy plugins, arguing that proposal-based governance "treat[s] every action as what is effectively an onchain referendum" and that the operational reality of an organization is "repeated, structured, and predictable" rather than novel. Under that model an organization configures a rule once for a bounded, known action type, and the system then executes matching transactions with, in Aragon's words, "no discretionary involvement or trusted intermediaries", reserving proposals for genuinely novel decisions such as protocol upgrades or changing the policies themselves (Beyond Proposals Pt. I: Automation and the Art of Not Governing).

This does not make execution free either. It converts a recurring per-proposal cost into a standing infrastructure cost and moves it from the member who clicks to whoever operates the policy, which is a different distribution rather than an absence. What it does change is the denominator. A DAO that routes payroll, vendor top-ups and rebalancing through a policy stops paying the full deliberate-decide-execute cycle for transactions whose decision was already made, and that cycle, not the gas, is the expensive part. It is the same argument governance minimization makes about scope, applied to the execution step specifically.

Why the cost stays invisible

Three properties keep this off every ledger, and they compound.

1. It is paid in the wrong currency by the wrong party. The DAO's budget is denominated in its treasury assets and spent by proposal. Execution gas is paid in the chain's native token out of a private wallet. No treasury outflow occurs, so no accounting system sees an expense at all.
2. It has no owner, so it has no reporter. Every other governance cost surveyed in DAO governance operating costs, from steward compensation to strategy firms to legal entities, has a party who requested a budget and therefore reports against it. Execution has no requester. A cost class with no claimant produces no line item, whatever its size.
3. Success looks identical to a subsidy. When a delegate or a protocol team quietly executes every proposal out of its own pocket, the DAO observes proposals landing on time and concludes the process works. The subsidy is only visible on the day it stops, which is the same information failure DAO tooling discontinuity identifies in dependencies that are maintained by goodwill until they are not.

The practical consequence is a concentration nobody chose. In practice the party that executes is usually the protocol's own core team or a small number of committed delegates, because they are the ones watching. That is a soft form of the executor role the permissionless design was written to avoid, arrived at through cost rather than through code, and it is invisible to anyone reading the contracts. A DAO that wants to know whether it has this exposure can answer it directly: pull the ProposalExecuted events for the last year and count distinct senders. If the answer is a handful of addresses, the DAO has an unfunded operational dependency on those addresses, whatever its governance documentation says.

How Caper approaches this

A caper treats settling a proposal as the caper's own cost rather than the settler's, and funds it from the fee that proposal already paid in.

Every call on the settle path draws gas against a per-proposal allowance held in the treasury. The per-call draw is capped at SETTLEMENT_GAS_PER_CALL, currently 5 XRD, and the per-proposal allowance at SETTLEMENT_GAS_BUDGET, currently 500 XRD, which is the same figure as the default proposal fee. The per-call figure is a ceiling rather than a charge: the engine refunds the unconsumed part of a fee lock, so overshooting costs allowance precision rather than funds. Because the allowance is sized to what the proposal contributed, a proposal funds its own execution and cannot draw the treasury down past its own fee. When the allowance is exhausted, the method still runs and the caller pays, so the design degrades to the industry default rather than bricking.

The mechanism that makes this safe is small and worth naming. The treasury draws with a contingent fee lock. A plain fee lock on the Radix engine is a force-write: it takes the XRD and survives a transaction abort, while the ledger write recording the draw does not. Under a plain lock, anyone could call a settle-path method, abort, and drain the treasury while the allowance counter rolled back. The contingent lock ties the payment to the transaction committing.

The honest limits: this covers the settle path for a caper's own proposals, not arbitrary automation, and it moves the cost onto proposers rather than removing it, since the proposal fee that funds settlement is paid by whoever proposes. The full mechanic, including which of the three draw sites gasses a read and which gasses a write, is on execution, and the fee schedule itself is admin-configurable rather than constant, as proposals sets out.

References

• OpenZeppelin, Governor.sol. The execute declaration, read from source.
• Compound, GovernorBravoDelegate.sol. The execute declaration and its single state guard, read from source.
• Chainlink, Automation billing and costs. Fee formula, the 80,000 gas overhead, the Polygon worked example, minimum balance and the 0.1 LINK cancellation fee.
• Chainlink, documentation index. The instruction to prefer CRE for new automation workflows.
• Gelato, Pricing plans. Plan tiers, compute-unit allowances and the autoscale rate.
• Aragon, Beyond Proposals Pt. I: Automation and the Art of Not Governing, 19 January 2026. Policy plugins and the case for reserving proposals for novel decisions.