Architecture
One layer, five responsibilities, one decision
PASS occupies a narrow position: after an actor has decided what it wants to do, and before a protocol carries it out. Everything below describes what happens in that interval, what has to be true for it to mean anything, and what remains outside its reach.
01System overview
From granted authority to settled value
Authority originates with a person or an institution and is written into a mandate. An actor operates under that mandate. When it proposes an execution, PASS derives what the call actually does, resolves the credentials and state the mandate depends on, applies the permissions and bounds, and returns a decision. Protocols execute. Assets settle.
Each responsibility is separable, and that separation is the point. A credential can be revoked without touching a mandate. A mandate can be amended without touching a key. An adapter can be added without rewriting policy. None of these operations requires the actor to cooperate.
- 01User / institutionDefines the intent and grants the authority
- 02MandateThat authority, written as a record
- 03Agent / executorProposes executions under the mandate
- 04PASSDetermines whether a proposed execution is permitted
- Credential layerResolves which attestations a subject holds
- Policy engineEvaluates permissions against the mandate
- Risk rulesApplies limits and accumulated exposure
- Execution preflightProduces the decision before submission
- Adapter layerDerives validated intent from a proposed call
- 05ProtocolsThe venues that carry out instructions
- Exchange
- Lending
- Derivatives
- Settlement
- 06Onchain assetsWhere value actually sits
02Parties
Four roles, deliberately kept distinct
Most confusion about permission systems comes from collapsing these into one another. The party that holds a key, the party whose capital moves and the party that vouches for an eligibility condition are rarely the same.
- Subject
The party whose capital and eligibility are at stake.
Authority originates here. A subject may be an individual, a fund, a desk or a treasury.
- Actor
The party that proposes executions on the subject’s behalf.
An agent, an execution service or an automated strategy. Holding a key makes an actor capable, not authorized.
- Issuer
The party that attests to a fact about a subject.
Performs verification outside the execution path and records only the conclusion as a credential.
- Integrator
The party that places the check in an execution path.
A protocol, an account module or an execution service. Determines how much of the path a decision actually governs.
03Subsystems
What each part of the layer is responsible for
Five subsystems, each with a defined input, a defined output and a defined behaviour when it cannot answer.
Resolves which attestations a subject holds at the moment of evaluation, and whether each is currently valid.
- Consumes
- Subject reference, required credential types
- Produces
- Held / not held, per required type
- Reason codes
- MISSING_CREDENTIAL · CREDENTIAL_EXPIRED · CREDENTIAL_REVOKED
A credential that has expired or been revoked is treated as absent rather than as a warning, so time and issuer action can both withdraw an authority without any mandate being rewritten.
Applies the permission sets of the governing mandate to the validated intent: which actor, which action, which asset, which venue.
- Consumes
- Execution intent, mandate
- Produces
- Permitted / refused, with the refusing rule
- Reason codes
- ACTOR_NOT_AUTHORIZED · ACTION_NOT_ALLOWED · ASSET_NOT_ALLOWED · ADAPTER_NOT_ALLOWED
Permissions are allow sets. Anything not named is refused, so an omission fails closed rather than granting silently.
Applies value bounds: the largest single movement permitted, and cumulative exposure across a period.
- Consumes
- Intent value, accumulated exposure for the period
- Produces
- Within bounds / exceeded
- Reason codes
- TX_LIMIT_EXCEEDED · DAILY_LIMIT_EXCEEDED
Value-denominated limits depend on a price input. That dependency is real and is treated as a trust assumption rather than as a solved problem.
Sequences the checks in a defined order and produces the decision that determines whether the call proceeds.
- Consumes
- Intent, mandate state, credential state, exposure state
- Produces
- Decision: outcome and exactly one reason code
- Reason codes
- AUTHORIZED · MANDATE_EXPIRED · MANDATE_SUSPENDED
Evaluation stops at the first refusing rule, so a refusal names one specific cause rather than summarising everything that might have been wrong.
Decodes a proposed call against a known target and derives the asset, action, value and venue that policy is evaluated against.
- Consumes
- Target address, calldata, value
- Produces
- Validated execution intent, or a refusal
- Reason codes
- INVALID_EXECUTION_CONTEXT
An adapter that cannot confidently decode a call refuses rather than guessing. This makes adapters security-relevant components in their own right.
04Mandate
Authority as a structure rather than a sentence
A mandate names the actor, the subject it acts for, the sets of permitted assets, actions and venues, the bounds on value, the credentials required as preconditions, and anything explicitly prohibited.
Because it is structured, it can be evaluated by a party that did not write it, amended without renegotiating anything else, and withdrawn by a party who does not hold the actor’s key.
{
"actor": "0x81…29F",
"subject": "0x7F…94A",
"assets": ["AAPL", "NVDA"],
"actions": ["BUY", "SELL"],
"venues": "approved-adapters",
"limits": {
"perTransaction": 2500,
"daily": 10000
},
"requiredCredentials": ["STOCK_TOKEN_ELIGIBLE"],
"prohibited": ["BRIDGE"]
}05Decision lifecycle
Where an execution can stop, and what it is told when it does
Evaluation runs in a defined order and halts at the first rule that refuses. A decision therefore carries exactly one reason code, and that code identifies a specific stage rather than summarising the whole.
Propose
An actor forms a call it would like to make and presents it under a mandate.
No terminal outcome
Validate
An adapter decodes the call against a known target and derives the execution intent.
- INVALID_EXECUTION_CONTEXT
Resolve
The actor’s binding is established, then mandate state and the credentials it requires are read as they stand now.
- ACTOR_NOT_AUTHORIZED
- MANDATE_EXPIRED
- MANDATE_SUSPENDED
- MISSING_CREDENTIAL
- CREDENTIAL_EXPIRED
- CREDENTIAL_REVOKED
Evaluate
Permissions and bounds are applied in a defined order against the validated intent.
- ACTION_NOT_ALLOWED
- ASSET_NOT_ALLOWED
- ADAPTER_NOT_ALLOWED
- TX_LIMIT_EXCEEDED
- DAILY_LIMIT_EXCEEDED
Decide
An outcome is returned with exactly one reason code identifying the first rule to refuse.
- AUTHORIZED
Settle
Execution proceeds, and accumulated exposure for the period is updated.
No terminal outcome
06Adapters
Deriving what a call actually does
Policy is evaluated against a validated intent, never against a description the caller supplies about itself. Producing that intent from opaque calldata is the adapter’s entire job.
- Raw callBytes proposed by an actor
- Protocol adapterDecodes against a known target
- Validated intentWhat is actually being proposed
- Asset
- Action
- Value
- Venue
- PASS policyEvaluated against the mandate
- ExecutionProceeds only on AUTHORIZED
This concentrates trust rather than removing it. An adapter is correct for one protocol, is allow-listed explicitly, and refuses any call it cannot decode with confidence rather than returning a guess.
07Trust boundaries
Which components sit inside which boundary
A permission layer is only as good as its inputs. Every component the architecture touches falls into one of three regions, and each region fails in a different way.
Granted
Trusted by construction
- Subject
- Mandate author
- Chosen scope
A mandate is enforced exactly as written. The architecture has no opinion about whether the authority granted was the right amount.
Evaluated
Must be correct
- Policy engine
- Credential resolution
- Adapters
- Exposure accounting
A defect inside this boundary can permit an execution that policy should have refused, or refuse one it should have permitted.
External
Assumed, not verified here
- Credential issuers
- Price inputs
- Target protocols
Where an external input is wrong, a decision can be correct in form and wrong in substance. Nothing inside the layer can detect that.
08Integration surface
Where the check is placed determines what it governs
The same decision can sit in three different positions. They differ in how much of the execution path they cover, and in what has to be adopted for them to work.
- 01
In the executing contract
Every caller
Closest to the point of no return and impossible to route around, but it requires the target protocol to adopt the check.
- 02
In a guard in front of an account
Every transaction from that account
Covers an actor across all venues it can reach, and requires no change to the protocols it trades against.
- 03
At the actor’s execution boundary
That actor only
Simplest to adopt and useful immediately, but it constrains an actor that cooperates rather than one that does not.