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.

What makes an authorization standing

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:

• Scope — which parameters or accounts the mandate may touch. Universally present; a mandate with no scope is just an admin key.
• Magnitude — how far a single exercise may move the parameter, or how much it may spend.
• Direction — whether the holder may only act one way. The strongest constraint available, because a one-way power cannot be used to undo the DAO's own decisions.
• Frequency — a cooldown between exercises, which converts a fast attack into a slow one the DAO has time to notice.

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.

Four mechanisms, read at source

Lido: Easy Track motions

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: the debt-ceiling instant-access module

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: risk stewards

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: the pause guardian

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.

The dial nobody sets

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.

Where duration is bounded: elected cohorts

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.

When the mandate replaces the vote

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.

How Caper approaches this

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 kinds — pay a recipient, buy another caper's token, sell one back down its curve, cast a vote inside another caper, or (for $CAPER only) upgrade the platform logic. 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.

References

• Lido, Guide to Easy Track — objections threshold, motion duration and the committee list.
• Lido, MotionSettings.sol and EasyTrack.sol — the contract-level bounds and the objection accounting.
• Lido, LIP-3: Easy Track motions.
• MakerDAO, DssAutoLine.sol — setIlk, and the asymmetry inside exec.
• BGD Labs, RiskSteward.sol and IRiskSteward.sol — RiskParamConfig and _validateParamUpdate.
• Compound, Comptroller.sol — the pause guardian's one-way requirement.
• The Arbitrum Foundation, Arbitrum DAO Constitution, Section 4: Security Council Elections.