Architecture

PASS occupies a narrow and specific segment of the path between a decision and its effect. Everything upstream of that segment — how an actor formed an intention, what model or desk produced it — is outside the system. Everything downstream — how a venue fills an order, how a lending market prices collateral — is also outside it. What the architecture defines is the part in between: the point at which a proposed execution is turned into a structured claim of authority, evaluated against machine-readable rules, and either admitted or refused with a deterministic reason.

The system in one view

USER / INSTITUTION
        |
        | issues mandate
        v
     MANDATE  <---- POLICY (rules it is built from)
        |
        | binds actor to subject
        v
ACTOR / EXECUTOR
        |
        | proposes execution
        v
+------------------------------------------+
|                  PASS                    |
|                                          |
|  ADAPTER LAYER    -> Execution Intent    |
|  CREDENTIAL LAYER -> subject standing    |
|  POLICY ENGINE    -> permission result   |
|  RISK RULES       -> limit accounting    |
|  PREFLIGHT        -> Decision + Reason   |
+------------------------------------------+
        |
        | AUTHORIZED only
        v
PROTOCOLS
exchange | lending | derivatives | settlement
        |
        v
ONCHAIN ASSETS

The path has a direction and it does not fold back on itself. A user or institution is the source of authority. It expresses that authority as a mandate, which is assembled from policy rather than written as free text. The mandate names an actor and a subject and states what the actor may do on the subject's behalf. The actor — a person, a desk, a service, or an autonomous agent — proposes an execution. PASS evaluates the proposal. Only an authorized proposal reaches a protocol, and only a protocol moves assets.

Two properties of this ordering matter. The first is that authority is expressed before the moment of execution and evaluated at the moment of execution; the actor does not negotiate its own permissions in the middle of a trade. The second is that refusal is cheap. A blocked proposal produces a decision and a Reason Code, not a reverted transaction whose cause has to be reconstructed from a trace.

Subsystems

Adapter layer

An adapter is protocol-specific decoding. It takes a raw call and produces an Execution Intent: a normalized statement of actor, subject, action, asset, venue and value. The adapter model exists because calldata cannot be trusted to describe itself. The same byte string means different things at different targets, a function selector is not a semantic guarantee, and a call that resembles a transfer may be a bridge entry point. An adapter converts an opaque call into a claim that policy can be evaluated against, and it is allowed to fail. If no adapter covers the target, the intent is not decodable and preflight refuses with INVALID_EXECUTION_CONTEXT. If an adapter exists but the mandate does not admit that venue, the refusal is ADAPTER_NOT_ALLOWED.

Credential layer

The credential layer resolves the subject's passport and reports which attestations it currently holds, who issued them, and whether they are live. It decides nothing. It reports standing: present, expired, revoked, absent. For the running example, passport 0x7F...94A carries IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE, AML_CHECKED and STOCK_TOKEN_ELIGIBLE. A mandate that requires STOCK_TOKEN_ELIGIBLE is satisfied on that dimension; a mandate requiring an attestation the passport does not carry is not, and preflight refuses with MISSING_CREDENTIAL. The architecture supports privacy-preserving credential models and external attestations, so a credential can be represented as a proof of a property rather than as the underlying data.

Policy engine

The policy engine evaluates the Execution Intent against the mandate. It checks that the actor is the actor the mandate names, that the mandate is live rather than expired or suspended, and that the action, asset and venue fall inside the grant. Its outputs are categorical. A proposal submitted by an address the mandate does not name draws ACTOR_NOT_AUTHORIZED before any of its content is examined. An intent to buy AAPL through an approved adapter is inside the running mandate; an intent to buy an asset outside the allowed set draws ASSET_NOT_ALLOWED; an intent to bridge draws ACTION_NOT_ALLOWED, because that mandate blocks bridging.

Risk rules

The risk rules are the quantitative half of the same evaluation, and they are policies like any other. They compare the intent's value against the mandate's per-transaction ceiling and against the exposure already accumulated in the current period. In the running example a $2,500 maximum transaction and a $10,000 daily exposure limit are separate constraints: a $3,000 order fails on the first with TX_LIMIT_EXCEEDED even when the day is untouched, and a $2,000 order fails on the second with DAILY_LIMIT_EXCEEDED once $8,400 has already been used.

Execution preflight

Preflight is the coordinator and the only component that returns a verdict. It calls the layers in a fixed order, stops at the first refusal, and returns a decision consisting of an outcome and one Reason Code. Determinism is a requirement rather than a convenience: the same intent, against the same state, must produce the same code, or the code cannot be used for reconciliation, alerting or dispute. Preflight MUST refuse an intent it cannot validate. Absence of a rule is not permission.

The decision lifecycle

PROPOSED EXECUTION
        |
        v
DECODE            -> INVALID_EXECUTION_CONTEXT
        |
        v
EXECUTION INTENT     actor, subject, action,
        |            asset, venue, value
        v
ACTOR AND MANDATE -> ACTOR_NOT_AUTHORIZED
        |            MANDATE_SUSPENDED
        |            MANDATE_EXPIRED
        v
CREDENTIAL CHECK  -> MISSING_CREDENTIAL
        |            CREDENTIAL_REVOKED
        |            CREDENTIAL_EXPIRED
        v
PERMISSION CHECK  -> ACTION_NOT_ALLOWED
        |            ASSET_NOT_ALLOWED
        |            ADAPTER_NOT_ALLOWED
        v
LIMIT CHECK       -> TX_LIMIT_EXCEEDED
        |            DAILY_LIMIT_EXCEEDED
        v
AUTHORIZED
        |
        v
EXECUTE, THEN RECORD USAGE

The order is not arbitrary. Decoding comes first, because nothing can be evaluated about an intent that has not been derived. Binding and mandate state come next, and credentials after them, because a suspended mandate or a withdrawn attestation disposes of every proposal under it regardless of content. Categorical checks come before quantitative ones, since a disallowed asset does not become allowed at a smaller size. Usage is recorded after execution rather than at proposal time, so that refused and abandoned proposals do not consume a subject's daily capacity. The full sequence, step by step, is set out in preflight.

The interface a call site depends on is small.

interface IPreflight {
    struct ExecutionIntent {
        address actor;
        address subject;
        bytes32 action;
        address asset;
        address venue;
        uint256 value;
    }
 
    struct Decision {
        bool allowed;
        bytes32 reason;
    }
 
    function preflight(ExecutionIntent calldata intent)
        external
        view
        returns (Decision memory);
 
    function record(ExecutionIntent calldata intent) external;
}

A refused decision carries the same shape as an authorized one. Onchain the decision is returned in reduced form, so the caller reads one boolean and one code: allowed is true exactly when the record's outcome is AUTHORIZED. That code is the same value carried into logs and reconciliation. The record below is the refusal of a $3,000 buy under the running mandate, written for subject 0x3A...F02 against the passport the credential layer resolved for it.

{
  "actor": "0x81...29F",
  "subject": "0x3A...F02",
  "passport": "0x7F...94A",
  "action": "BUY",
  "asset": "NVDA",
  "venue": "approved_adapter",
  "value": 3000,
  "decision": {
    "outcome": "BLOCKED",
    "reason": "TX_LIMIT_EXCEEDED"
  }
}

Trust boundaries

No architecture removes trust. It relocates and narrows it. Each component here is trusted for one property, and it is worth stating plainly what breaks when each is compromised.

The last row is the point of the design. A compromised key is a serious event, and PASS does not make it harmless. It bounds it. An attacker holding actor 0x81...29F's key inherits that actor's control, not unlimited authority: the assets remain AAPL and NVDA, the ceiling remains $2,500 per transaction and $10,000 per day, and bridging remains refused. Wallets and signature schemes address key control well; they were not built to answer whether a given action was permitted, and PASS does not replace them. The adapter row is the sharpest dependency in the table, because a decoder that misreads a call causes policy to evaluate a fiction. For that reason the security model requires an adapter to be reviewed before its target is admitted, and requires an unrecognized target to be refused rather than guessed at.

Where the check is placed

AGENT BOUNDARY     -> earliest, weakest
        |
        v
GUARD MODULE       -> account level, portable
        |
        v
EXECUTING CONTRACT -> latest, strongest

The evaluation is identical at all three placements. The guarantee is not, and it strengthens as the check moves closer to the state change it governs. A check at an agent's boundary is the most informative and the weakest, since it constrains a cooperating agent while nothing compels a compromised one to consult it. A guard module constrains every call one account makes, across protocols, without modifying any of them. A check inside the executing contract shares a transaction with the effect it governs and cannot be bypassed by any caller, at the cost of requiring that contract to be written or upgraded to call it. The placements compose rather than compete, and the integration model works through the trade-offs between them.

State and time

Two kinds of state are evaluated. Credentials and mandates have validity windows, compared against the timestamp at evaluation, which is why lapse produces CREDENTIAL_EXPIRED or MANDATE_EXPIRED rather than silent continuation. Limits accumulate. A daily exposure limit is a counter over a defined period, and the architecture requires that period boundary to be explicit rather than inferred, because "daily" is ambiguous across time zones and rolling windows. Usage is written on execution, so accounting reflects what happened rather than what was proposed.

Suspension is deliberately distinct from expiry and revocation. A mandate can be suspended and later resumed without being reissued, and MANDATE_SUSPENDED is therefore a live control — the mechanism a principal uses to halt an agent immediately without unwinding the grant.

What the architecture keeps outside itself

Custody is not part of PASS. The system evaluates authority over an execution; it does not hold assets and does not stand between an owner and their property. Strategy is not part of PASS. Whether buying NVDA is a sound decision is a question the architecture takes no position on, since it answers only whether this actor may do it under this mandate. Price discovery and settlement remain with the venues and protocols that perform them.

These exclusions are load-bearing. A permission layer that also custodied assets would become the concentration of risk it was meant to reduce, and one that evaluated strategy would need information it cannot verify. PASS constrains authorization risk specifically: market, smart-contract, oracle and governance risk are unaffected by a correct authorization decision, and are treated in the security model.