Once a proposal's voting window closes and its execution delay has elapsed (roughly ten minutes by default), anyone can submit the transaction that carries out the winning option. The delay is a deliberate pause between the decision and the act — the same role a timelock plays in mainstream DAO governance, giving members a window to react before an executive action lands.

The resolve gate

Execution first re-tallies the ballot on-chain and checks that the leading option cleared the 1.5 / N supermajority. If it did not — or if the no-execution option won — the proposal simply finalizes with no action. A proposal can be resolved only once.

Single call vs multi-step

TEXT options are legislative — they carry no on-chain action, so there is nothing to execute. A winning TEXT proposal stands as a recorded signal (see Proposals); only executive options reach the treasury.

PAYOUT and INVEST each execute in a single call. PAYOUT transfers the chosen currency and amount out of the treasury. INVEST runs its whole withdraw → buy → deposit inside the contract's own call frame, so the treasury XRD it spends never touches the transaction worktop — a public executor cannot take part of the withdrawal and pocket the rest. The settling step asserts the bucket handed back is the target caper's token, in a positive amount, before it lands in the treasury.

VOTE is the one action split across several manifest instructions, because it must re-enter a separate component mid-transaction. A first call hands the manifest the target token, the XRD vote fee, and the treasury admin badge; the manifest presents that badge as a proof to authorise the treasury's vote into the target caper's proposal, routed through a fresh top-level frame; a final call returns the badge to its vault. Because the whole sequence is one atomic transaction, the admin badge never survives a transaction boundary outside the vault — if any step fails, the entire execution rolls back.

Hand-rolling an executor manifest

If you ever build an executor manifest by hand, end it with a try_deposit_*_or_abort: the Radix Engine's General transaction classifier only whitelists the _or_abort deposit variants, and the _or_refund forms make the wallet display a "Complex transaction" warning instead of a clean summary.