Concept
From assistants to actors
The change worth attention is not that software has become better at analysis. It is that software can now issue instructions that move money, along a path built on the assumption that a person had already approved them.
This page sets out the problem PASS addresses: what changed, what the controls already in that path establish, and what has to exist before an autonomous actor is given capital to work with.
01The shift
An assistant proposes. An actor issues.
For most of the history of financial software, the output was a proposal. A person supplied the authority by accepting it.
A screener ranks instruments. A risk model prices a book overnight. An execution front end assembles an order and waits. In each case a person approves what the software produced, and that approval is where a great deal of financial control has always lived: a role, a limit and a signature decide that this particular thing may happen.
Autonomous execution removes that step for some class of decisions. Given an objective, access to venues and the ability to sign, software can select an action and issue it. The people involved still set the objective, choose the tools and review what happened. What they no longer do is approve each action before it takes effect.
What autonomous systems do well
- Watch continuously, across more venues than a desk can hold in view.
- Decompose an objective into concrete steps and carry them out in order.
- Act within seconds of a condition being met, at any hour.
What they do not establish
- That the objective was understood the way it was meant.
- That behaviour holds under inputs nobody anticipated.
- That an action was within the authority of the party they act for.
The question the execution path has to answer has changed. Not only whether the instruction is well formed, but whether this actor was permitted to issue it.
03Existing controls
Why a private key is not a mandate
Four mechanisms already sit in this path. Each solves a real problem. None was designed to produce the fact that is missing.
| Mechanism | What it establishes | What it leaves open |
|---|---|---|
| Private key | That this account authorized this transaction. Control is provable and identical for every party checking it. | Whether the account should have. A key is total within its account: everything that account can do, or nothing. |
| Wallet permission systems | Bounded capability inside one account: session keys, spending caps, allowlisted targets, expiry. Real constraints, and they hold. | What the actor was authorized to do for the party it represents. The bound describes one account and is legible to that account implementation. |
| Application logic | Rules enforced where the application runs: eligibility, exposure checks, review above a threshold. | Every path that does not go through the application. An actor holding a key is not obliged to use the interface carrying the rules. |
| Model instructions | Direction. Language is the right way to state intent to something that reasons in language. | Nothing outside the actor is aware of the instruction, and nothing downstream can confirm it was followed. |
The gap is not a defect in any of them. It is that none produces a portable statement of financial authority: one record naming the actor, the party it acts for, the assets and actions permitted, the amounts allowed, the venues approved and the conditions attached, in a form something in the execution path is obliged to evaluate before the call proceeds.
That record is what PASS calls a Mandate.
04Machine-readable mandates
Authority written as a record rather than as a sentence
Most financial authority already exists in writing. It is written for people to read, and it is inert to everything else in the path.
Investment policy statements, delegations of authority and trading limits agreed with a risk function are precise by the standards of prose. A limit written as a sentence still has to be read by a person and translated into whatever the executing system supports. The translation is where authority quietly changes shape.
As written for people
The agent may trade AAPL and NVDA for this account, up to $2,500 per transaction and $10,000 in a day, at approved venues only, and only while the account holds a valid stock-token eligibility attestation. It may not bridge assets.
Unambiguous to a reader. Unavailable to anything in the execution path.
As written for execution
- Actor
- 0x81…29F
- Acting for
- Subject account
Permissions
- Allowed assets
- AAPL
- NVDA
- Allowed actions
- BUY
- SELL
- Allowed venues
- Approved adapters only
- Bridging
- Blocked
Limits
- Maximum transaction
- $2,500
- Daily exposure
- $10,000
Conditions
- Required credential
- STOCK_TOKEN_ELIGIBLE
- Validity
- Bounded window, revocable at any time
The record states the same content in named fields. Permitted assets are an allow set rather than a description, so an asset that is not named is not permitted. Limits are numbers rather than adjectives. The required credential, STOCK_TOKEN_ELIGIBLE, refers to an attestation held in the subject Passport, 0x7F…94A, alongside IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE and AML_CHECKED.
- Amendment
- Narrowing an actor to one asset is an edit to a field, not an argument about wording.
- Expiry
- Authority ends at a stated time by default. Nobody has to be present to withdraw it.
- Revocation
- The granting party withdraws a mandate without touching the actor key. A withdrawn credential falls away from every mandate that requires it.
- Independent verification
- A counterparty, an operator or an auditor evaluates the mandate directly, rather than asking the actor what it may do.
Each of those states produces an outcome when it is the reason an execution does not proceed.
- CREDENTIAL_REVOKEDCredentialA required credential was withdrawn by its issuer.
- MANDATE_EXPIREDLifecycleThe governing mandate is past its validity window.
- MANDATE_SUSPENDEDLifecycleThe mandate is temporarily inactive.
- ACTOR_NOT_AUTHORIZEDLifecycleThe actor is not bound to a mandate for this subject.
05Enforcement at execution time
A boundary is a rule that something other than the actor evaluates
A constraint can sit at four points between an objective and settlement. The positions are not equivalent, and only one of them produces something a counterparty can rely on.
- 01ObjectiveWhere an actor is told what to attempt
- 02ApplicationWhere one application enforces its own rules
- 03Execution pathWhere the call is evaluated before it proceeds
- 04SettlementFinal; no later evaluation withdraws it
The first two positions are useful and neither is dispensable. An objective is the right place to say what an actor should be trying to do; an application is the right place to enforce its own rules. To anything downstream, though, both are advisory: nothing obliges the path to consult them.
The third position is different, and not because it is stricter. It is unavoidable. The call does not proceed unless an evaluation returns a decision that permits it. That is what separates a boundary from advice, and it is why the check belongs at the last moment when refusing is still inexpensive. Onchain settlement is built to be final; after it, the remedies are commercial and legal rather than technical.
Evaluated case
Actor 0x81…29F proposes a $4,000 trade in AAPL. The asset is permitted, the venue is an approved adapter, and the subject holds STOCK_TOKEN_ELIGIBLE. The mandate sets a maximum transaction of $2,500.
The refusal names the rule that refused rather than reporting a general failure, which is what makes it correctable: the same actor proposing $2,000 in the same asset at the same venue is inside the mandate.
A decision is an assertion about policy and nothing else. AUTHORIZED states that an execution was within the authority granted. It makes no claim about whether the trade is a good one, whether the counterparty is solvent, or whether the target protocol behaves as expected.
06The PASS model
Six primitives, one decision
PASS sits between autonomous financial actors and onchain execution. It evaluates, before capital moves: who may act, what they may do, where they may execute, how much they may move, and under which conditions.
- 01
Passport
Who is this, and what can they prove?
The identity record for a subject. It holds credentials issued by Issuers — IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE, AML_CHECKED, STOCK_TOKEN_ELIGIBLE — each revocable by the party that issued it.
- 02
Mandate
What is this actor permitted to do?
The authority one Actor holds to act for one Subject: permitted assets and actions, approved venues, limits, required credentials, a validity window.
- 03
Policy
Which rule decides, and in what order?
The rules applied to a proposed execution, evaluated in a fixed order, so the same inputs produce the same outcome and the same reason.
- 04
Adapter
What is this call actually doing?
Reads a proposed call at one protocol and derives the asset, action, venue and value. An adapter that cannot decode a call refuses it rather than guessing.
- 05
Preflight
May this proceed, now?
The evaluation performed before the call is submitted, against the derived Execution Intent rather than a description the actor gives of its own transaction.
- 06
Decision
What happened, and why?
An outcome and a stable Reason Code, so the caller, the log and an audit trail agree on why an execution did or did not proceed.
- 01Proposed callRaw calldata, opaque until something decodes it
- 02AdapterDerives asset, action, venue and value
- 03PreflightEvaluates the derived intent
- PassportCredentials the subject holds
- MandateAuthority granted to the actor
- PolicyRules applied in a fixed order
- 04DecisionAn outcome and a reason
- AUTHORIZEDEvery applicable rule was satisfied
- Reason codeThe first rule that refused
Nothing in that sequence depends on an actor describing its own transaction, and nothing depends on an actor remembering a constraint.
Two directions from here
The architecture page describes how the layer is composed: where the evaluation sits relative to accounts, adapters and venues, and what each component is responsible for. The problem note in the documentation states the same argument in a technical register, with the reason code taxonomy attached.
PASS is an independent protocol project. References to third-party networks, protocols or companies are architectural context and do not imply affiliation or endorsement.