Mandates
Mandates define the authority an agent may use over controlled capital and the boundaries around it.
A Mandate is an authority grant connecting an agent to controlled capital. It defines what the agent may propose, the boundaries around those actions, and the conditions under which more approval is required.
What a Mandate establishes
A Mandate can describe:
- the agent allowed to act;
- the Vault covered by the authority;
- permitted actions and their limits (native amounts, native-USD amounts,
SWAProutes); - conditions that must hold before an action proceeds (Preflight floors);
- when the authority is valid (
validAfter/validUntil); - when additional approval is required;
- whether narrower authority may be delegated; and
- how the authority begins, changes, and ends.
The model can expand with new actions, assets, conditions, and approval paths while keeping the same basic authority boundary.
Authority is bounded
A Mandate does not give an agent unrestricted control. It grants a defined area of authority, and every Action Plan is checked against the boundaries that apply when it is evaluated.
Updates can change what an agent is allowed to do. Revocation permanently stops future use of the authority. Pausing temporarily suspends it without destroying the record.
Lifecycle
A Mandate has three possible states:
- ACTIVE: the authority can be used for evaluation and execution.
- PAUSED: temporarily suspended. Blocks execution, escalation submission and approval, and new child Mandate creation. Deposits, withdrawals, and Mandate administration still work. Resuming restores the same authority.
- REVOKED: permanently stopped. Cannot be resumed. The original records and history are preserved.
ACTIVE → PAUSED → ACTIVE (resumable)
ACTIVE → REVOKED (permanent)The Vault controller and authorised parent agents can pause and revoke within their respective boundaries.
Validity windows
Each Mandate carries validAfter and validUntil timestamps. The authority cannot be used outside this window. Before validAfter, the Mandate is not active. After validUntil, it stops being active. A value of 0 for either field means no constraint on that side.
Validity windows intersect across lineage. A child's effective window is the tightest combination of every active ancestor:
effective validAfter = latest ancestor validAfter
effective validUntil = earliest ancestor validUntilThis is different from the Action Plan deadline, which limits one signed proposal. A Mandate window applies to the authority itself.
Effective authority
The authority an agent can use is the effective authority that remains after the current Mandate is combined with every active ancestor above it:
effective authority
= current Mandate
∩ active ancestor boundariesThis is why a child Mandate cannot broaden the authority that created it, and why revoking an ancestor affects the descendants below it. The current contracts apply this model to the implemented Mandate limits, escalation permissions, delegation permission, the Preflight rules, and the validity window. Pausing an ancestor also blocks descendant execution.
Authority lineage
Mandates form a lineage when an authorised agent delegates a narrower grant to a sub-agent. The current contracts support a root Mandate, a child Mandate, and one further sub-agent level (maximum depth of 2). At depth 2, canDelegate is forced off so no further delegation is possible.
A proposal is valid only when the authority behind it, including any relevant ancestors, remains active and unpaused.
See Delegation for the general inheritance model and Decisions for how a proposal's result is expressed.
Last updated on