Core concepts

Six primitives carry the whole of PASS: Passport, Mandate, Policy, Adapter, Preflight and Decision. Each one isolates a part of a single question — may this actor do this specific thing, right now, for this subject — so that the parts can be authored, held, evaluated and audited by different parties at different times. A credential is issued long before it is used. A mandate is written before the actor it binds has anything to do. An intent exists for a moment. A decision is kept. Separating them is what makes authority machine-readable rather than a matter of after-the-fact interpretation.

None of the six authorizes anything on its own. Authority is what the evaluation produces when they are brought together and compared, before capital moves.

Subject, Actor and Issuer

Three roles appear throughout the specification, and conflating any two of them reintroduces the problem PASS exists to address.

The Subject is the party on whose behalf authority is exercised: a fund, a treasury, an entity, a person — subject 0x3A...F02 in the running example. Eligibility attaches to the subject. Whether a purchase of a tokenized equity is permissible turns in part on facts about the subject that the mechanics of the transaction do not carry.

The Actor is the party exercising the authority: an address, an agent process, a trading service, a desk. In the running example, actor 0x81...29F holds a key and can therefore sign. Signing establishes control. A protocol that accepts the resulting instruction establishes validity: the call is well formed and executable. Neither establishes authority, which is the separate question of whether this actor was permitted to do this particular thing, for this subject, under these constraints.

The Issuer is the party attesting to a credential: a verification provider, a compliance function, a registry, an administrator. An issuer asserts that something is true of a subject. It does not decide what the actor may do with that truth.

ISSUER
   |  attests about
   v
SUBJECT ---- grants authority ---> ACTOR
                                     |
                                     v
                            proposes execution

The separation matters because each role fails differently. A compromised key is an actor problem. A revoked eligibility is a subject problem. A dishonest attestation is an issuer problem. A system that treats the signer as the principal cannot tell these apart, and cannot express the ordinary situation in which an actor is legitimate, the instruction is valid, and the action is still not permitted.

Passport

A passport is a credential container bound to a subject. It holds attestations — eligibility, jurisdiction, verification status — each naming its issuer, its subject, its validity window and its revocation state. Passport 0x7F...94A, bound to subject 0x3A...F02, carries IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE, AML_CHECKED and STOCK_TOKEN_ELIGIBLE.

The problem a passport solves is that policy needs facts a transaction cannot supply. Nothing in a signature, a nonce or a calldata string indicates whether the subject is permitted to hold the asset being acquired. Those facts are established elsewhere, and they need a durable representation that an evaluation can read at the moment it is needed.

A passport is not an identity document, not a verification process, not a wallet and not a permission. Holding STOCK_TOKEN_ELIGIBLE authorizes nothing; it satisfies a condition that a mandate may require. The architecture supports privacy-preserving credential models and external attestations, meaning a credential can reference an attestation maintained by its issuer and can assert a property without carrying the underlying material. A credential's usefulness derives from the standing of its issuer, which the architecture treats as an explicit, checkable parameter rather than an assumption. The credential model is set out in passports.

Mandate

A mandate is machine-readable financial authority. It binds an actor to a subject and states what that actor may do, within which limits, for how long. The mandate in the running example allows the assets AAPL and NVDA, caps any single transaction at $2,500, caps daily exposure at $10,000, restricts venues to approved adapters, requires the credential STOCK_TOKEN_ELIGIBLE, and blocks bridging.

A mandate is an authority object, not an instruction. It describes what may happen and never what will. It has a lifecycle independent of any transaction: it can expire, producing MANDATE_EXPIRED, and it can be suspended, producing MANDATE_SUSPENDED, without anything changing at the key level and without the actor losing its ability to sign.

A mandate is not a key, not a role and not an allowance. A token allowance answers how much of one asset a spender may move; it says nothing about which action is being taken, which venue is used, whether the subject remains eligible, or how much has already moved today. Role-based access control answers group membership. Both mechanisms solve real problems, and solve them well within their scope; a mandate addresses a different one, which is the expression of bounded economic authority with denominations, windows and conditions attached to it. Field-level structure is given in mandates.

Policy

A policy is a machine-enforceable rule, and a mandate is assembled from a set of them. Each policy is independently evaluable and constrains exactly one dimension: an asset allowlist, an action allowlist, an adapter allowlist, a per-transaction ceiling, a rolling exposure limit, a credential requirement, a validity window, an actor binding.

Two properties follow from keeping policies separate from the mandates that use them. The first is reuse: a jurisdiction constraint authored once can appear in many mandates and be reasoned about in one place. The second is diagnosis. Because every policy failure resolves to a defined Reason Code, a refusal can name its cause instead of returning an undifferentiated failure.

A credential requirement distinguishes three failures rather than one: MISSING_CREDENTIAL where the attestation was never held, CREDENTIAL_EXPIRED where its validity window has closed, and CREDENTIAL_REVOKED where the issuer has withdrawn it. The distinction is operational as well as formal, because the three call for different responses. A mandate in a suspended state is refused before its policies are reached, with MANDATE_SUSPENDED.

Policies are conjunctive: every applicable policy must pass for an intent to be authorized. The running example blocks bridging, so an intent whose action is a bridge fails the action allowlist and returns ACTION_NOT_ALLOWED whatever its size and whatever else it satisfies. Evaluation order does not change the outcome, but it does determine which cause is reported when more than one would fail, so the order is fixed to keep the reported reason deterministic. The policy catalogue is in policies.

Adapter and Execution Intent

At the EVM level, a transaction is a target address, a value and a byte string. The same four-byte selector means different things in different contracts. A purchase, a deposit, a bridge and an approval are, at that level, the same kind of object: a call to a contract. Calldata cannot be trusted to describe itself, and that is the reason the adapter model exists.

An adapter is protocol-specific decoding that turns a raw call into a validated Execution Intent. It knows one protocol's encoding and is responsible for producing an accurate economic description of what the call would do — or for refusing to produce one. An adapter that cannot decode a call declines to emit an intent, and preflight refuses with INVALID_EXECUTION_CONTEXT rather than proceeding on an inference. Adapters are themselves allowlisted by policy, so a call routed through an unapproved adapter yields ADAPTER_NOT_ALLOWED.

The Execution Intent is the normalized, validated description of the proposed action: asset, action, value and venue, attributed to an actor and a subject.

interface ExecutionIntent {
  actor: Address;
  subject: Address;
  action: 'BUY' | 'SELL' | 'TRANSFER' | 'BRIDGE' | 'APPROVE';
  asset: AssetIdentifier;
  value: Decimal; // normalized notional
  venue: AdapterId;
  context: ExecutionContext;
}

Policy is evaluated against the intent rather than against calldata because policy statements are economic and calldata is not. A rule that caps a transaction at $2,500 and restricts assets to AAPL and NVDA has no meaning against a byte string. It has a precise meaning against an intent stating that the action is a purchase, the asset is NVDA, the notional is $2,400 and the venue is an approved adapter. Evaluating raw bytes would force every policy to re-implement the semantics of every protocol it might encounter. The adapter localises that knowledge in one reviewable place.

An adapter is not a router, an executor or a bridge. It moves nothing; it decodes and validates. Decoding requirements are detailed in adapters.

Preflight

Preflight is the evaluation performed on a proposed execution before it is carried out. It takes the Execution Intent, the mandate that governs the actor and subject, the passport that carries the subject's credentials, and the accumulated state that rolling limits depend on. It runs the policy set and returns a decision.

Preflight is deterministic, and it must be able to refuse. An intent it cannot validate is not authorized: the absence of a reason to block is not a reason to allow. Preflight must also be evaluated against the same state the execution would use, because an authorization computed against stale exposure or a stale revocation record is an authorization for a different world than the one the transaction lands in.

The dependence on state is not incidental. Suppose the actor in the running example has already executed $9,100 of purchases within the current day. A proposed $1,200 purchase of AAPL satisfies the asset allowlist, satisfies the credential requirement and sits within the $2,500 per-transaction ceiling. It fails on one dimension only: executed exposure plus the proposed notional reaches $10,300, past the $10,000 daily limit. The decision is a refusal carrying DAILY_LIMIT_EXCEEDED. That every other policy passed does not soften the result, because the policy set is conjunctive.

Preflight is not a simulation of outcome and not risk management. It answers an authorization question and nothing beyond it: a mandate can bound how much exposure an actor may take, but market, smart-contract, oracle and governance risk in the venues an intent touches are left where the security model describes them. The evaluation procedure is specified in preflight.

Decision

A decision is the result of preflight: an outcome plus a deterministic Reason Code. A $3,200 purchase of NVDA proposed against the running example exceeds the per-transaction ceiling and resolves to the following.

{
  "outcome": "BLOCKED",
  "reason": "TX_LIMIT_EXCEEDED",
  "actor": "0x81...29F",
  "subject": "0x3A...F02",
  "passport": "0x7F...94A",
  "intent": {
    "action": "BUY",
    "asset": "NVDA",
    "value": "3200.00"
  },
  "constraint": {
    "policy": "maxTransactionValue",
    "limit": "2500.00"
  }
}

The code is the interface, not the message. Human-readable text drifts as it is edited, translated and reworded, and anything built on top of it drifts with it. A stable code serves three consumers at once. An autonomous actor needs to distinguish conditions it can respond to from conditions it cannot: DAILY_LIMIT_EXCEEDED means wait, TX_LIMIT_EXCEEDED means propose a smaller execution, and ASSET_NOT_ALLOWED means the request falls outside the mandate and retrying accomplishes nothing. An operator aggregating decisions can only count what is labelled consistently; CREDENTIAL_EXPIRED recurring across many subjects is an operational signal, and free text is not. An auditor needs a record that names a cause, since "blocked" is not a record while CREDENTIAL_REVOKED against a named credential, mandate and intent is.

AUTHORIZED is a Reason Code with the same standing as the refusals. An authorization is a positive statement produced by the same evaluation and written in the same shape, which is what allows a decision log to be a complete account of exercised authority rather than a list of exceptions.

How the primitives compose

   PASSPORT       MANDATE     EXECUTION INTENT
      |              |              |
      +--------------+--------------+
                     |
                     v
                 PREFLIGHT
                     |
                     v
     DECISION = OUTCOME + REASON CODE

Each input arrives from a different source and on a different timescale. The passport comes from issuers and changes when an attestation is granted, expires or is revoked. The mandate comes from the subject and changes when authority is granted, narrowed, suspended or allowed to lapse. The Execution Intent comes from the actor by way of an adapter and exists only for the duration of the evaluation. Preflight is the point at which the three are compared. The decision is what remains afterwards.

The composition runs in one direction: issuers describe subjects, policies constrain, mandates bind actors to those subjects, and adapters describe what a proposed call would do. Preflight compares the three, and the decision is what remains once it has. Nothing in that chain confers authority by itself, and nothing later in the chain can recover authority that was never expressed earlier in it. The field-level definitions of each object, and the fixed evaluation order that makes Reason Codes deterministic, are set out in the specification; how the pieces are arranged at runtime is described in the architecture.