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. The per-tier prices this page carried until 1 September 2026 have been removed, because they can no longer be sourced: docs.gelato.cloud answers every path with a Vercel DEPLOYMENT_NOT_FOUND page, including the documentation link on Gelato's own homepage, and the archive cannot stand in for it; re-probed on 20 September 2026, nineteen days on, with the same result. The last capture of the pricing page, 7 June 2026, preserves one sentence – “Choose a plan and get Compute Units you can use across all Gelato products” – and no table, because Mintlify renders the plan grid in the browser. A figure that only exists after hydration is not in the document any crawler, link checker or archiver ever saw, so it dies silently with its host. The shape is what survives, and 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.
- 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.
- 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.
- 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 used to treat settling a proposal as the caper's own cost, and since 11 September 2026 it does not: whoever cranks the settle path pays their own network fee, which is the industry default this page describes.
Until that date every call on the settle path drew gas against a per-proposal allowance held in the treasury, capped at SETTLEMENT_GAS_PER_CALL (5 XRD) a call and SETTLEMENT_GAS_BUDGET (500 XRD) a proposal, and the budget was written equal to the flat 500 XRD proposal fee so that a proposal funded its own settlement. The treasury drew with a contingent fee lock, because a plain lock is a force-write that survives an abort while the allowance counter does not. The redeploy of 11 September 2026 removed all of it – lock_settlement_fee, the allowance ledger and both constants – after a pen-test found the subsidy was wider than it looked: the Radix engine consumes locked fees in reverse lock order, so the treasury's lock was drawn before the caller's and paid the first 5 XRD of any transaction containing one settle-path call, whatever else that transaction did. A reimbursement scoped to the crank could not be built on that ordering, so it was removed rather than repriced.
What remains lowers the cost rather than paying it. Since the same redeploy settle_proposal folds up to 60 uncounted ballots itself (SINGLE_PASS_MAX_VOTERS), so a small proposal settles in one crank rather than a tally volley followed by a settlement, and a passed action must be executed within seven days of its resolution or it lapses (EXECUTION_WINDOW_SECONDS). The 500 XRD proposal fee is now purely a spam gate and bounds no settlement cost. The execution mechanics are on execution, and the fee schedule, written into the logic component at instantiation with no setter to move it, is on proposals.
References
- OpenZeppelin, Governor.sol. The
executedeclaration, read from source. - Compound, GovernorBravoDelegate.sol. The
executedeclaration 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, archived 7 June 2026. Cited for the subscription model only. The live host returns
DEPLOYMENT_NOT_FOUND, and no capture carries the tier table. - 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.