A standing authorization is a decision a DAO takes once about a class of future actions rather than about a single action. Instead of voting to raise a debt ceiling, the DAO votes on a formula that raises it; instead of voting on each grant, it votes on a committee with a budget and a spending envelope. Every action that lands inside the envelope executes without a further ballot.
This is the most common answer to a problem the wiki documents from the other side on voter apathy: an electorate that cannot summon a quorum for routine business will not become more engaged if you give it more routine business. Lido's own documentation states the motivation plainly – Easy Track was built "as a solution to the problem of the DAO getting tired of governance". The cost is that a DAO which delegates enough of its recurring decisions can arrive at a state where the treasury is busy and the ballot box is empty, and nothing in the mechanism announces that it has happened.
An ordinary proposal names a recipient, an amount and a moment. A standing authorization names none of those. It fixes four things instead, and the interesting variation between real designs is which of the four they bother to fix:
A fifth bound – duration, an expiry after which the mandate lapses unless renewed – is the one most often missing. It is also the only bound that forces the DAO to hold the vote again.
Lido's Easy Track (introduced as LIP-3) gives named committees the right to start a motion that passes by default. A motion is enacted if objections stay below a threshold for the motion's duration; enactMotion carries no role gate at all, so once the window closes anyone may execute it. Objections are one per address, weighted by LDO balance at the motion's snapshot block, and the motion is deleted the instant the running total crosses the threshold rather than at the end of the window.
The committees are listed in Lido's own guide and span node-operator staking limits, the Simple DVT and Community Staking modules, the LEGO grants programme, the Liquidity Observation Lab, the Rewards Share programme, the RCC, PML and ATC operating entities, the TRP multisig, gas rebates and treasury swaps. That is a wide surface of recurring spending that no LDO holder votes on individually.
What is worth reading in MotionSettings.sol is the gap between what the contract permits and what the DAO configured. The contract allows an objections threshold as loose as MAX_OBJECTIONS_THRESHOLD = 500 basis points (5%), a duration as short as MIN_MOTION_DURATION = 48 hours, and as many as MAX_MOTIONS_LIMIT = 24 live motions. Lido runs at 0.5%, 72 hours and 20. The DAO chose to be bound an order of magnitude more tightly than its own code requires on the objection dial, and more tightly on the other two – a deliberate margin that only shows up if you compare the deployment against the source.
Maker's DssAutoLine removes a governance vote from the loop entirely rather than delegating it to people. Governance calls setIlk(ilk, line, gap, ttl) once, fixing a maximum ceiling, a step size and a cooldown. After that exec(ilk) is external and unauthenticated: anyone may call it, and it sets the ceiling to min(debt + gap, line).
The asymmetry in that function is the design. An increase is refused if block.timestamp < lastInc + ttl, so the ceiling can only be raised once per cooldown; a decrease is subject to no such check and may be applied by anyone at any time. The mandate is rate-limited in the direction that adds risk and unlimited in the direction that removes it. This is direction and frequency bounded together, with no human holder to trust at all.
Aave's RiskSteward hands a risk council the right to move supply caps, borrow caps, e-mode settings, interest-rate curves and price caps without a governance vote. Its interface reduces the whole mandate to a two-field struct per parameter, RiskParamConfig { uint40 minDelay; uint256 maxPercentChange }, and _validateParamUpdate enforces exactly those two: it reverts DebounceNotRespected when the parameter moved more recently than minDelay, and UpdateNotInRange when the change exceeds maxPercentChange. A separate guard rejects any update to zero.
Governance keeps two levers as owner – setRiskConfig to retune the bounds and setAddressRestricted to carve individual assets out of the mandate. There is no expiry anywhere in the contract.
Compound's Comptroller is the cleanest example of a purely directional mandate. Each of _setMintPaused, _setBorrowPaused, _setTransferPaused and _setSeizePaused carries the same pair of requirements: the caller must be the pause guardian or the admin, and then require(msg.sender == admin || state == true, "only admin can unpause"). The guardian may stop the protocol and may never restart it. Its worst case is a denial of service that governance can reverse; it cannot be used to open anything.
Read together, the four mechanisms converge on the same three bounds and skip the fourth. Easy Track bounds magnitude through per-factory limits and frequency through the 72-hour window; DssAutoLine bounds magnitude by gap, direction by the increase-only cooldown and frequency by ttl; RiskSteward bounds magnitude by maxPercentChange and frequency by minDelay; the pause guardian bounds direction absolutely. None of them expires.
That is a defensible engineering choice – an expiring pause guardian is a hole waiting for a lapsed renewal – but it has a governance consequence that is rarely stated. Because the mandate does not expire, the DAO is never forced to revisit it, and the natural review trigger is an incident rather than a calendar. A mandate granted to a committee that has since lost its members, or scoped to a market the DAO no longer runs, stays live and stays invisible, which is the same failure the wiki records under council dissolution: bodies are far easier to create than to wind up.
The practical counterweight is a timelock on the mandate's own configuration, so retuning the bounds is itself slow and visible, plus a periodic inventory of who currently holds what. Neither is a substitute for an expiry.
The four mechanisms above were each built by one protocol for one job. In January 2026 Aragon proposed making the standing authorization a standard part of its OSx framework, as a class of plugin it calls a policy plugin: "a set of rules for a known, bounded action type" that lets an organisation act repeatedly without asking its members again (Aragon). Governance plugins, by contrast, handle decisions that still need a proposal.
Aragon describes four parts: one job, such as distributing funds; deterministic logic that checks on-chain conditions and builds the transaction when they hold; a settings layer with the recipients, amounts and timing, which Aragon calls political; and an override that lets a proposal change those settings. Execution is permissionless, so anyone may trigger a policy once its conditions hold, the same choice Lido made for Easy Track. Aragon's examples are the recurring business this page describes: monthly budget splits to team multisigs, buybacks, burns, vendor top-ups, payroll and rent.
Against the bounds above, the design fixes scope by construction and puts magnitude and frequency into the settings. Duration is not among the four parts, so a policy runs until a proposal changes it. Aragon promised a second part on encoding financial policy; it had not appeared by 19 September 2026.
The mechanism that does carry a hard expiry is not a parameter mandate but a seat. Arbitrum's DAO Constitution gives its Security Council twelve members split into two cohorts of six, with an election every six months that replaces one cohort. A seat is therefore a twelve-month term that ends whether or not anyone proposes to end it, and the authorization it carries dies with it unless the holder is re-elected.
The election rules are themselves shaped against capture: a contender must be pledged at least 0.2% of all Votable Tokens to reach the ballot, a sitting member of one cohort may not stand for a seat in the other, and in the final voting window votes cast after T+35 days carry linearly decaying weight through T+49 – a deliberate penalty on deciding the outcome at the last moment. The pattern to take from it is that DAOs already know how to time-bound authority; they apply it to people and not to parameters. See security councils and emergency powers for the powers themselves.
The end state a standing authorization can reach is visible on this wiki in one fully documented case. Long COVID Labs' proposal DP-6, which closed on 7 October 2025 with fifteen addresses voting, authorized a token generation event, a funded liquidity pool, and – the clause that matters here – authority for the operating multisig to pursue further DEX and CEX listings "without requiring new governance proposals". No proposal has been put to that DAO since. The treasury has visibly continued to execute the budget the DAO approved; the ballot box has been idle for the whole period.
Nothing there was a breach. Every action taken sat inside a mandate the holders granted on the record. But it shows what the missing duration bound produces at the limit: a DAO whose last governance act was to make further governance acts unnecessary. The measurable symptom is not a failed vote – it is the absence of votes alongside continuing treasury activity, which is a diagnostic any DAO can run against itself and almost none do. It is worth pairing with delegate accountability, where the same silence is read from the voter's side rather than the treasury's.
A caper has no standing authorization of any kind, and this is a structural fact rather than a policy. Its treasury moves only through the settlement of one specific proposal: every execution entry point in the contract takes a cashtag and a proposal id, and every option a proposal can carry is one of five typed executive kinds – pay a recipient, buy another caper’s token, sell one back down its curve, rewrite the mutable metadata on the caper’s own token, or (for $CAPER only) upgrade the platform logic – or, since 5 September 2026, a DEBATE option, which is ranked alongside them and can win the tally but authorises nothing (proposals). There is no recurring option, no stream, no committee address, and no role that can act on the treasury between proposals.
The trade is real and runs both ways. A caper cannot delegate its routine spending to a grants committee, so it pays the full attention cost of every decision; the mechanisms above exist precisely because that cost is what exhausts large DAOs. What it buys is that the diagnostic in the previous section can never come back positive: treasury activity and governance activity are the same events, so a caper cannot be busy and ungoverned at once. The pressure valve is on the other side – a member who dislikes where the treasury is going does not need a veto or a committee seat, only the exit.
MotionSettings.sol and EasyTrack.sol – the contract-level bounds and the objection accounting.DssAutoLine.sol – setIlk, and the asymmetry inside exec.RiskSteward.sol and IRiskSteward.sol – RiskParamConfig and _validateParamUpdate.Comptroller.sol – the pause guardian's one-way requirement.