Mandates

A key can sign. A protocol can confirm that an instruction is well formed. Neither states that a particular actor was permitted to move a particular asset, on behalf of a particular subject, within a particular limit, at this moment. A mandate is the object that states it. It is written so that a machine can read it without interpretation, and it is evaluated by preflight before execution rather than reconstructed afterwards by a human reading transaction logs.

Everything else on this page follows from one property: a mandate is data that is evaluated, not a permission that is remembered.

The binding

A mandate binds an actor to a subject under a granting authority.

The actor is the account that signs and submits. It may be an autonomous agent, an execution service, or a person operating a terminal. The subject is the party on whose behalf capital moves, identified by a passport that carries the subject's credentials. The granting authority is the party whose own authority the mandate is carved out of. It is a distinct role from the issuer that attests to a credential, and the two are rarely the same party.

These are three separate roles, and conflating them is the failure mode the primitive exists to prevent. An actor holding a key has control over an account. Control is not authority over a subject's capital. The mandate is what makes the relationship explicit, bounded and machine-checkable.

GRANTING AUTHORITY
        |
        v
     MANDATE  --binds--> ACTOR  for  SUBJECT
        |
        +--> allowed assets, actions, venues
        +--> per-transaction and daily limits
        +--> required credentials
        +--> validity window
        +--> explicit prohibitions

What a mandate carries

The fields below are the constraint surface. Each is checked during preflight against an Execution Intent derived by an adapter, and each has a deterministic Reason Code on failure.

Two fields deserve more than a row. The daily exposure limit is not a property of the actor; it is a function of executions accumulated inside a defined window, so it cannot be evaluated from a single intent and requires state that persists between executions. The required credentials field is a reference rather than a copy: it names credential types, and preflight resolves them against the subject's passport at evaluation time. A credential that was valid yesterday and has since lapsed produces CREDENTIAL_EXPIRED or CREDENTIAL_REVOKED without the mandate itself changing at all.

None of these fields is bespoke to a single mandate. Each is an instance of a policy: a machine-enforceable rule type — an asset allow set, a value ceiling, a windowed accumulator, a credential requirement — with its parameters filled in. The policy is the rule; the mandate is the bound instance that names an actor, a subject and specific values. Keeping the two apart means a rule can be specified and reasoned about once, while the mandates assembled from it differ only in their parameters.

The example mandate as a record

MANDATE
  subject            passport 0x7F...94A
  actor              0x81...29F
  allowed assets     AAPL, NVDA
  allowed actions    BUY, SELL
  allowed venues     approved adapters only
  max transaction    $2,500
  daily exposure     $10,000
  required creds     STOCK_TOKEN_ELIGIBLE
  validity           2026-01-01 .. 2026-12-31
  prohibitions       BRIDGE
  status             ACTIVE

Read as a whole, the record answers the five authority questions for one actor: who may act, what they may do, where they may execute, how much they may move, and under which conditions execution may proceed. Expressed as an interface, the same record is the shape that policy evaluation reads.

// Conceptual interface sketch. Field shapes are illustrative.
interface Mandate {
  subject: Address; // Passport the authority is exercised for
  actor: Address; // account permitted to act
  allowedAssets: AssetId[];
  allowedActions: Action[];
  allowedAdapters: Address[];
  maxTransactionValue: bigint; // per execution, in quote units
  dailyExposureLimit: bigint; // cumulative per window, in quote units
  exposureWindow: Seconds; // canonical window is one day
  requiredCredentials: CredentialType[];
  notBefore: Timestamp;
  notAfter: Timestamp;
  prohibitions: Action[];
  status: 'ACTIVE' | 'SUSPENDED'; // revocation removes the binding
}

Evaluating an intent against the record

A mandate carries no meaning on its own. It acquires one in the presence of a proposed execution. Preflight takes the Execution Intent an adapter derived from the raw call and checks it against the record above, against the subject's passport, and against the exposure already accumulated inside the current window.

EXECUTION INTENT
  actor   0x81...29F
  action  BUY
  asset   AAPL
  value   $3,000
        |
        v
POLICY CHECK
        |
        v
BLOCKED  ->  TX_LIMIT_EXCEEDED

The same record produces the following decisions for five proposed executions, each evaluated against the mandate above.

The third row is the case a per-transaction ceiling cannot detect on its own. A $1,200 purchase sits well inside the $2,500 limit and is refused anyway, because $9,400 has already been committed inside the window and settling this execution would carry cumulative exposure to $10,600. Every other row can be decided from the intent and the record alone; that one cannot.

Where more than one constraint fails, the decision still carries a single Reason Code. Which code is returned follows from the evaluation order defined by preflight rather than from the mandate, so a Reason Code should be read as the reason execution stopped, not as an exhaustive account of everything wrong with the intent. A blocked decision leaves the record untouched. Refusal is an outcome of evaluation, not an event in the life of the mandate.

Allow sets, not deny sets

A mandate enumerates what is permitted. Anything not enumerated is refused. The alternative — a deny set listing forbidden assets, venues and actions — requires the author to anticipate every dangerous case in advance, and the set of dangerous cases grows every time a new asset is listed, a new venue is deployed, or a familiar function selector is reused for an unfamiliar purpose. A deny set fails open on everything nobody thought of. An allow set fails closed on it.

The cost is real and should be stated plainly. An allow set must be maintained. A new venue requires an amendment before the actor can use it. A mandate written too narrowly produces refusals that look, from the operator's side, like an outage. The trade is deliberate: a refused execution can be reviewed and re-proposed, while an unauthorized execution that settles cannot be recalled.

Explicit prohibitions exist alongside the allow set for a different reason. If everything unlisted is already refused, a prohibition adds nothing at the moment it is written. It adds something later. A prohibition on bridging is checked against the action in the derived Execution Intent, not against a call target, so it survives amendments to the venue list. Adding an adapter that happens to expose a bridging path does not silently widen the mandate, because BRIDGE remains prohibited at the action level and the decision is ACTION_NOT_ALLOWED. Prohibitions constrain what future amendments can accidentally permit.

Scope and delegation

A mandate can be narrower than the authority of the party that granted it. It can never be broader. Delegation is intersection, not addition.

GRANTED AUTHORITY
   assets   AAPL, NVDA, MSFT
   max tx   $25,000
        |
        v   delegation narrows, never widens
DELEGATED MANDATE
   assets   AAPL, NVDA
   max tx   $2,500
        |
        v
EFFECTIVE PERMISSION = INTERSECTION OF THE CHAIN

A desk holding authority over three instruments up to $25,000 per transaction can delegate a mandate covering two of them at $2,500. It cannot delegate a mandate permitting a fourth instrument, a higher ceiling, or an action outside its own scope. Where a chain of delegation exists, the effective permission is the conjunction of every link, so the chain can only tighten as it lengthens.

One operational consequence is worth stating directly. Suspending a mandate high in a chain removes authority from everything beneath it, and no downstream party can restore what an upstream party has withdrawn. Containment acts from the top down.

Lifecycle

A mandate has four states and a small number of transitions between them.

Creation makes a mandate evaluable: the granting authority issues it and the binding between actor and subject is recorded. Amendment replaces field values and takes effect at the next preflight. Because evaluation always reads current state, an amendment never retroactively authorizes an execution that already settled, and never retroactively invalidates one. Suspension is a reversible hold, used when something looks wrong and the correct response is to stop and examine it. Revocation removes the binding permanently. Expiry ends the validity window without anyone acting.

The registry defines no revocation-specific code, and the omission is deliberate. Suspension holds a binding in place and therefore has a code that names it. Revocation removes the binding, so at the next evaluation the intent presents an actor for whom no authority exists, and ACTOR_NOT_AUTHORIZED describes that state accurately.

A mandate in good standing can still produce a blocked decision. If the subject's passport no longer carries STOCK_TOKEN_ELIGIBLE, the decision is MISSING_CREDENTIAL and the mandate is untouched. The separation is useful in operations, because the two failures call for different responses: one is an authority question that belongs to the granting party, the other an eligibility question that belongs to the issuer.

Evaluated, not remembered

A mandate is not a session token, an approval, or a cached grant. A prior AUTHORIZED decision confers nothing on the next proposed execution. Every intent is evaluated against the current mandate state, the current credential state of the passport, and the current accumulated exposure inside the window.

This is why suspension takes effect at the next evaluation rather than at the end of a session, why a lapsed credential blocks the next trade even though it permitted the last one, and why a daily limit cannot be held as a counter by the actor. An actor never presents a decision. It presents an intent, and the decision is produced outside it.

What a mandate is not

A wallet spending limit constrains how much value can leave an account, sometimes per token and sometimes per period. That is a genuine control and it prevents genuine losses. It is also a single field of a mandate, attached to a key rather than to a relationship. A spending limit does not know which subject the capital belongs to, whether the destination venue is approved, whether the decoded action is a swap or a bridge, or whether an eligibility attestation is still valid. Expressing delegation is outside what it was designed for, and in the common configuration it can be changed or removed only by the key holder.

A prompt instruction is different again. Telling a model to trade only within a list of tickers describes intent to a system that can increasingly make and execute decisions on its own. The instruction is advisory, difficult to version, and nothing standing between the model and the chain is obliged to evaluate it. A mandate sits outside the actor and is evaluated whether or not the actor behaves as its operator expects. The two are complementary: the prompt shapes what an agent attempts, and the mandate determines what is permitted.

Finally, the scope of the guarantee. A mandate constrains authorization. It does not remove market risk, smart-contract risk at the venue, oracle risk in the valuation used to convert an intent into the quote units a limit is denominated in, or governance risk in whoever holds the granting authority. A $2,500 ceiling is only as meaningful as the price source used to measure against it, which is one of the trust assumptions discussed in security.