Permission infrastructure
PASS is the permission layer for autonomous finance — identity, policy and execution infrastructure for onchain capital markets.
01The shift
For most of its history, financial software helped people decide. It ranked options, modelled outcomes and prepared instructions that a person then approved.
A new requirement begins here
03ExecuteSoftware issues the instruction itself.Autonomous systems can increasingly do more than prepare an instruction. Given an objective, a set of tools and the ability to sign, software can select an action and issue it without a person reviewing that particular decision.
The change is narrow but consequential. The final step in the sequence is no longer a recommendation someone accepts or rejects. It is an execution, and execution moves capital. The infrastructure question this raises is not whether software can act. It is what a given piece of software is permitted to do.
02The missing layer
Follow a transaction from an autonomous actor to settlement. Every component in the path does its job correctly. None of them is responsible for the question that matters most.
Unresolved at this point
Financial agents need permissions, not just private keys.
03Introducing PASS
A person or an institution already knows what an actor should be allowed to do. That intent normally lives in a policy document, a risk committee decision, an operating agreement or an instruction given to an operator. It is written for people, and it is enforced by people.
PASS turns that intent into a form execution infrastructure can evaluate: an explicit statement of which actor may act for which party, over which assets, at which venues, within which limits, subject to which credentials, and for how long.
The result is not advice given to an actor. It is a boundary evaluated independently of it.
04Permission dimensions
A mandate is not a single switch. It is a set of independent constraints, each of which can refuse an execution on its own, and each of which produces a distinct reason when it does.
A refusal is never general. It names the dimension that produced it.
05Without PASS / With PASS
The difference is not that one path has permissions and the other has none. It is where those permissions live, what they are expressed in terms of, and whether anything in the path is obliged to check them.
Permission model
Trust the agent.
Example mandate
Verify every execution.
Each mechanism on the left solves a real problem. A key proves control, an API key scopes a service, instructions shape behaviour and application logic enforces rules where it runs. What none of them produces is a single statement of financial authority that holds across accounts, applications and venues, and that something in the execution path is required to evaluate.
06Preflight
A proposed execution is normalized into an intent — an asset, an action, a value and a venue — and evaluated against the governing mandate. The result is a decision, and the decision is what determines whether the call proceeds.
Rules are evaluated in a defined order, and evaluation stops at the first failure. A refusal therefore carries exactly one reason code: the specific constraint that was not satisfied, not a summary of everything that might have been wrong.
PASS preflight
Final decision
AUTHORIZED
Every applicable rule was evaluated and satisfied. The execution proceeds.
PASS preflight
Final decision
BLOCKED
ReasonTX_LIMIT_EXCEEDED
Evaluation stops at the first failing rule, so the decision carries exactly one reason code. Nothing was submitted.
07Passport
Many financial permissions depend on facts about a party rather than on the party’s identity: whether they are eligible to hold a particular instrument, whether a jurisdictional restriction applies, whether a screening was completed and by whom.
A Passport holds those facts as credentials — stable identifiers attested by an issuer. A mandate can then require a credential without any part of the execution path needing the underlying documentation, and an application can check eligibility without becoming a custodian of personal data.
The architecture supports privacy-preserving credential models and external attestations, and treats the issuer relationship as a first-class part of the design rather than an afterthought.
Credentials
Permissions
Limits
Conditions
08Mandate
A mandate binds an actor to the party it acts for and states, in financial terms, what that actor may do. It is expressed as allow sets and bounds rather than as prohibitions, so an asset, an action or a venue that is not named is not permitted.
Because it is a record rather than an instruction, it can be amended, suspended, revoked or allowed to expire without touching the actor’s key and without the actor being asked to cooperate.
The agent may decide.
PASS defines the boundary.
09Deterministic enforcement
Both of the constraints below express the same intention. They differ in who evaluates them, and when.
Instruction to an actor
“Don’t spend more than $10,000 today.”
Evaluated by the actor, at the time it reasons, as one input among many. It shapes what the actor attempts. Nothing else in the execution path is aware of it.
Machine-enforceable bound
mandate.limits = {
perTransaction: 2_500,
daily: 10_000,
};Evaluated by the execution path, at the moment the action would occur, against accumulated state the actor does not maintain and cannot report on its own behalf.
Evaluated case
A $1,400 trade, against $9,200 already moved today, would carry cumulative exposure past the daily bound.
BLOCKEDDAILY_LIMIT_EXCEEDEDA financial permission should not depend on the agent remembering the instruction.
This is a statement about where a constraint is evaluated, not a claim that instructions are without value. An instruction is a useful way to direct an actor. It is not a boundary that a counterparty, an operator or an auditor can rely on, because nothing outside the actor is obliged to check it.
11Adapter model
If an actor could tell the permission layer what its own transaction was — that these bytes are a $500 trade in AAPL — the check would be decorative. The description and the call would be independent of each other.
Raw calldata is opaque by design. The same bytes mean different things at different targets, token amounts are not values, and a value requires a price. An adapter closes that gap for one protocol: it verifies the target, decodes the call, identifies the asset and computes the value, producing an intent that policy can be evaluated against.
This shifts trust rather than removing it. Adapters become security-relevant components, adapter correctness becomes a property the system depends on, and an adapter that cannot confidently decode a call has to refuse it rather than guess. That refusal is itself a decision, with the reason code INVALID_EXECUTION_CONTEXT.
12Architecture
The map is the whole system. Authority is granted by a party, written as a mandate, exercised by an actor, evaluated by PASS, carried out by a protocol and settled onchain. Six positions, and the layer occupies exactly one of them.
What that position buys is separability. The credential, the mandate, the adapter set and the key are four different objects, and each is changed on its own.
13Why now
None of these is new on its own, and none of them individually creates a permission problem.
Separately, none of these needed a permission layer. Arriving in one execution path, they do.
14Ecosystem
Environments are emerging in which tokenized financial assets, DeFi mechanisms, programmable accounts and automated execution sit in one place. Robinhood Chain is publicly described as an environment of that kind.
Convergence of that kind raises questions that neither the asset layer nor the execution layer is positioned to answer. Tokenized instruments can carry eligibility conditions. Venues differ in what they are approved for. Exposure needs to be bounded across a whole book rather than one transaction. And the party proposing an action is increasingly a program.
Those are permission questions, and they are the same questions regardless of which chain the assets happen to sit on.
15Developers
Integration is a single call placed where an action becomes irreversible. It returns an outcome and a reason, and the caller either proceeds or refuses.
The same shape holds whether the check runs inside an executing contract, in a guard in front of an account, or at an agent’s own execution boundary. What changes is how much of the path is covered by it.
// Evaluated before the action is carried out.
(bool allowed, bytes32 reason) = pass.checkPolicy(
account,
target,
asset,
action,
amount
);
if (!allowed) {
revert PolicyRefused(reason);
}// Evaluated before the call is submitted.
const decision = await pass.checkPolicy({
account,
target,
asset,
action: 'BUY',
amount,
});
if (!decision.allowed) {
return refuse(decision.reason);
}A decision carries allowed and reason. A refusal names the specific rule that was not satisfied, so a caller can distinguish a missing credential from an exceeded limit without inspecting the mandate.
16Design principles
Permissions are checked where an action becomes irreversible, not earlier in a process that can be skipped.
Financial authority is stated. It is not inferred from what a key happens to be able to reach.
Establishing eligibility should not require personal information to be written onchain.
A limit that matters is evaluated by the execution path rather than held in the memory of the actor it constrains.
A permission layer belongs above individual venues, so that authority is not redefined once per protocol.
Deciding what may happen does not require holding the capital it governs, and the architecture is designed so that it never needs to.
PASS
The permission layer for autonomous finance.