Introduction

Financial software is changing category. For most of its history it has been advisory. It ranked options, modelled outcomes, produced a recommendation, and then waited. A person read the output and decided whether to act. That person was the authorization layer, and because the layer was human it never had to be written down. Approval, hesitation, escalation and refusal were things a person did, informed by a mandate they understood, a role they held, and consequences they were exposed to.

Autonomous financial actors move that boundary. Software can increasingly make and execute decisions: read market state, select a venue, construct a transaction, sign it and submit it, on a timescale where human review of each action is not practical. This is not inherently reckless, and an autonomous actor is not assumed here to be adversarial. A competent, carefully built actor raises the same question as a careless one: on whose authority, and within which limits, does it act? The problem is structural rather than behavioural. When the human step is removed from the execution path, the authorization layer that lived inside that step is removed with it, and nothing in the current stack takes its place. What breaks when execution outpaces review is developed in detail on the problem page.

What remains is control and validity. Neither is the same thing as authority, and that difference is the reason PASS exists.

Control, validity and authority

A private key establishes control. Possession of the key means an account can produce a signature the network will accept as originating from that account. Control answers a narrow question: who is signing. It says nothing about whether the signer should have signed this particular instruction. A key that controls a hundred dollars and a key that controls ten million dollars are, at the cryptographic layer, the same object.

A protocol establishes validity. A correctly encoded instruction that satisfies the contract's preconditions — sufficient balance, correct arguments, a market that exists — will execute. Validity answers whether the instruction is well formed and executable. It does not answer whether it was permitted. A protocol has no view on whether the actor submitting a trade was allowed to trade that asset, in that size, on behalf of that subject, today.

Neither establishes authority. Authority is the question of whether this actor was permitted to do this specific thing, for this subject, under these constraints, at this moment. Authority has always existed in finance. It is the substance of an investment mandate, a trading limit, a delegated power of attorney, an eligibility rule, a jurisdictional restriction. Until now it has been enforced by people reading documents, by compliance review, and by after-the-fact reconciliation. Those mechanisms are real and they work at human speed. They do not survive contact with software that executes in seconds.

PASS makes authority machine-readable and evaluates it before execution. It is the permission layer for autonomous finance: identity, policy and execution infrastructure that sits between autonomous financial actors and onchain execution, and answers, before capital moves, who may act, what they may do, where they may execute, how much they may move, and under which conditions execution may proceed.

Where PASS sits

PASS occupies one position in the execution path and does not attempt to occupy the others.

   AUTONOMOUS ACTOR       <- decides what to do
          |
          v
     WALLET / KEY         <- holds control, signs
          |
          v
+-------------------------+
|          PASS           |  <- establishes authority
|   passport + mandate    |
|   adapter -> preflight  |
|   decision + reason     |
+-------------------------+
          |
    +-----+-----+
    |           |
    v           v
 BLOCKED   AUTHORIZED
 + REASON       |
                v
        ONCHAIN PROTOCOL   <- establishes validity
                |
                v
             CAPITAL

The actor still decides. The wallet still holds the key and still signs. The protocol still validates and still executes. PASS inserts one additional question between the decision and the settlement, and it answers that question first. Ordering is the point. An authorization system that reports after settlement is a reporting system: the capital has already moved, the position already exists, and the remedy is a reversal the chain may not offer. Evaluation before execution is what makes a limit a limit rather than an alert. Architecture describes how the components inside that box assemble into a single evaluation path.

The primitives

Six primitives carry the model. The definitions below are the vocabulary the rest of this documentation depends on, and each is developed in the pages that follow. The supporting terms they rely on — actor, subject, issuer, credential, Execution Intent and Reason Code — are set out in core concepts.

A passport describes a subject. It does not confer the right to act; it carries the credentials a rule may require, such as IDENTITY_VERIFIED or STOCK_TOKEN_ELIGIBLE. The architecture supports privacy-preserving credential models and externally issued attestations, so a policy can require proof of a property without requiring the underlying personal data to be disclosed onchain.

A mandate describes a relationship. It names an actor, names the subject on whose behalf that actor operates, and encodes the boundary of permitted action: allowed assets, allowed actions, transaction and daily value limits, approved venues, required credentials, and an expiry. A mandate is assembled from policies, the individual enforceable rules — an asset allowlist, a per-transaction ceiling, a credential requirement — that compose into a single authority statement.

An adapter reads the proposed call. This layer exists because calldata cannot be trusted to describe itself: a raw transaction to an unknown contract is an opaque byte string, and a permission system that guesses at its meaning is guessing about money. The adapter decodes the call against a known protocol interface and produces an Execution Intent, a normalized statement of action, asset, venue and value that policy can be evaluated against. Where no adapter applies there is no validated intent, and the correct outcome is refusal rather than assumption: a call that cannot be decoded returns INVALID_EXECUTION_CONTEXT, and a call that decodes cleanly but resolves to a venue the mandate does not permit returns ADAPTER_NOT_ALLOWED.

Preflight evaluates that intent against the mandate, the policies it contains, and the credentials in the passport. It returns a decision: an outcome and a deterministic Reason Code. Determinism matters more than it may first appear. A denial that cannot be explained is indistinguishable from a malfunction, and a system that cannot explain itself cannot be audited, reviewed, or given delegated authority over capital. The shape of that result is sketched below as an interface definition; the integration model develops how an actor obtains it.

interface Decision {
  outcome: 'AUTHORIZED' | 'BLOCKED';
  reason: ReasonCode; // AUTHORIZED, TX_LIMIT_EXCEEDED
  intent: ExecutionIntent; // what the adapter decoded
  mandate: MandateRef; // authority evaluated against
}

The model in one example

Consider an actor 0x81...29F operating under a mandate whose allowed assets are AAPL and NVDA, whose maximum transaction is $2,500, whose daily exposure limit is $10,000, whose venues are approved adapters only, which requires the credential STOCK_TOKEN_ELIGIBLE, and which blocks bridging. The actor acts for subject 0x3A...F02, whose passport 0x7F...94A carries IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE, AML_CHECKED and STOCK_TOKEN_ELIGIBLE.

Every row is decided by the same mechanism. An adapter derives the intent, preflight evaluates it against mandate and passport, and a decision is returned carrying a Reason Code drawn from a fixed set. The second row is worth dwelling on. The actor holds the key, the trade is well formed, and the protocol would have executed it. Control was present. Validity was present. Authority was not.

The order of evaluation

Preflight is an ordered sequence of checks rather than a single test, and the sequence is fixed so that the same intent, mandate and passport produce the same decision every time. It runs from the most fundamental condition to the most specific: whether an intent can be derived from the call at all, then whether the actor is bound to the mandate, whether that mandate is live, whether the required credentials are present and current, whether the action, the asset and the venue fall inside the grant, and last whether the value fits the transaction limit and the periodic one. A call that cannot be decoded is a reason to stop before any limit is compared, because a limit measured against an unvalidated intent is a number compared against a guess. The Reason Code returned names the first constraint that failed rather than an arbitrary one among several; preflight gives the full sequence and the code each step produces.

The example above resolves inside that order. The $4,000 purchase of AAPL clears everything ahead of the limits — the adapter decodes the call, the actor is the one the mandate binds, the mandate is live, STOCK_TOKEN_ELIGIBLE is present in the passport, buying is a permitted action, AAPL is an allowed asset, and the venue is an approved adapter — and then fails against the maximum transaction of $2,500. Nothing about the trade is malformed. It falls outside the authority granted, which is a different kind of failure and deserves a different answer.

A decision is therefore not an error condition. It is a result, and both outcomes carry information. AUTHORIZED states that the authority existed at the moment of evaluation. A blocking code states which constraint was reached, and that is what makes the outcome actionable: an actor that receives TX_LIMIT_EXCEEDED can infer that the same trade at or below $2,500 sits inside the mandate, while an actor that receives MANDATE_SUSPENDED can infer that no adjustment to the order will help. Explaining a refusal is part of enforcing it.

What PASS does not do

The boundaries are as load-bearing as the capabilities.

PASS does not custody capital. Assets remain where they are held, and the permission layer never takes possession of them. It does not execute trades: it evaluates a proposed execution and returns a decision, and the execution itself is performed by the actor against the protocol. It does not replace wallets, which solve key management and signing, or protocols, which solve settlement. It does not decide strategy. Whether a position is a good idea is outside its scope, and a fully authorized trade can still be a poor one.

Existing mechanisms are not dismissed here. Multisignature schemes, session keys, spending caps and contract allowlists solve real problems and solve them well within their scope. What they generally express is a constraint on a key or on a raw call rather than a constraint on a relationship: they can limit how much an address may spend, but not whether this actor may act for this subject, in this asset class, under these credentials, in this jurisdiction, until this date. PASS is aimed at that second question, and it composes with the first rather than competing with it.

PASS also constrains one class of risk and no other: it addresses authorization risk, not market, smart-contract, oracle or governance risk, which the security model treats in full.