Robinhood Chain

A market becomes programmable when three things that used to be separate become the same kind of object: the instrument, the venue, and the participant. A tokenized equity is an instrument a program can hold. A pool, a lending market or an order router is a venue a program can address directly. A programmable account is a participant a program can be. When all three occupy one execution environment, the distance between a decision and its settlement collapses to a single transaction.

That collapse is useful, and it is also where authority becomes the unresolved question. A private key establishes control: the account can sign. The venue protocol establishes validity: the instruction is well formed and executable given current state. Neither establishes authority — whether this actor was permitted to do this specific thing, for this subject, under these constraints. Programmable markets need programmable permissions for the same reason they need programmable settlement: because the thing being automated is no longer a form that someone reviews.

The convergence that raises the question

No single property of an environment makes it interesting to a permission layer. The convergence does. Four properties, appearing together in one place, change what has to be evaluated before capital moves.

TOKENIZED ASSETS      PROGRAMMABLE ACCOUNTS
        |                       |
        +-----------+-----------+
                    |
                    v
          ONE EXECUTION ENVIRONMENT
                    |
        +-----------+-----------+
        |                       |
  DEFI MECHANISMS       AUTOMATED ACTORS

Tokenized financial assets carry eligibility conditions that are not properties of the token contract. Whether a person or entity may hold a given tokenized instrument can depend on jurisdiction, verification status, professional classification, or sanctions screening. Token standards can encode transfer restrictions, and many do so competently. What a transfer restriction cannot express is why this actor is proposing this trade, on whose behalf, and against what budget.

DeFi mechanisms make execution composable. A single call can route through several venues, wrap and unwrap assets, or move value across a bridge. Composability is a genuine capability, not a defect. It does mean that the surface of an instruction is a poor description of its effect, which is why an adapter must decode a call into a validated Execution Intent before any rule is applied.

Programmable accounts — smart accounts, session keys, delegated signers — make delegation expressible and revocable at the account layer. This solves a real problem, and solves it well: an account can define which keys may sign what. Signing rights are still not financial authority. A module that permits a key to call a contract does not state that the actor holding that key may buy this asset, for this subject, up to this amount, today.

Automated execution completes the set. Actors that are software can increasingly make and execute decisions without a human reviewing each one. They are not omniscient and they are not necessarily adversarial. They are fast, and they act on their own reading of conditions, which means the interval in which a human might notice and intervene is often shorter than the interval in which the position is already open.

What each layer answers

The first three layers are not deficient. Each answers its own question correctly. The gap is that none of them is positioned to answer the fourth, because none of them holds the actor, the subject, the mandate and the intent at the same moment. Preflight is defined as the point where all four are present.

The four questions, made concrete

Consider the running example. Actor 0x81...29F operates under a mandate whose allowed assets are AAPL and NVDA, whose maximum transaction value 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. Passport 0x7F...94A carries IDENTITY_VERIFIED, NON_US_PERSON, EEA_ELIGIBLE, AML_CHECKED and STOCK_TOKEN_ELIGIBLE.

Eligibility attached to the instrument

The mandate requires STOCK_TOKEN_ELIGIBLE because the instrument class does. That requirement is evaluated against the passport as it stands at the moment of evaluation, not as it stood when the mandate was written. Eligibility is a moving property: an attestation can lapse, and an issuer can withdraw one. Preflight therefore distinguishes MISSING_CREDENTIAL from CREDENTIAL_EXPIRED and from CREDENTIAL_REVOKED, because the three describe different failures and call for different remedies.

Eligibility is also the point at which disclosure has to be bounded. Where a condition must be demonstrated without exposing the underlying documents, the architecture supports privacy-preserving credential models and external attestations, so that a passport carries the fact of a verification performed by an issuer rather than the material behind it. Preflight reads the attestation, not the file.

Venue constraints

Restricting execution to approved adapters is a statement about where authority extends, not a statement that other venues are unsound. If a call cannot be decoded by an adapter the mandate permits, the decision carries the Reason Code ADAPTER_NOT_ALLOWED. If it cannot be decoded into a coherent Execution Intent at all, the decision carries INVALID_EXECUTION_CONTEXT: preflight MUST refuse an intent it cannot validate, since calldata cannot be trusted to describe itself. The block on bridging resolves to ACTION_NOT_ALLOWED, and a proposed trade in an asset outside the allowed set resolves to ASSET_NOT_ALLOWED.

Exposure limits

The $2,500 transaction ceiling produces TX_LIMIT_EXCEEDED; the $10,000 daily exposure limit produces DAILY_LIMIT_EXCEEDED. Both attach to the mandate rather than to a venue, which is what makes them meaningful in a composable environment: the daily figure accumulates across every venue the actor touches. Where execution is fast and venues are interchangeable, a per-venue limit is a limit an actor can route around without ever violating it.

Actors that are software

Authority granted to a program is bounded in time and revocable in the middle of a session. An actor outside the mandate's authorized set yields ACTOR_NOT_AUTHORIZED. A mandate past its validity window yields MANDATE_EXPIRED. Suspension is a first-class state rather than an absence of permission, and yields MANDATE_SUSPENDED, so an operator can stop an actor without dismantling the authority that was granted to it.

One day of proposals

The constraints only mean something as a sequence. Below, each row is a proposed execution by actor 0x81...29F, evaluated in order against the same mandate on the same day.

Three properties of the table are deliberate. The transaction ceiling is inclusive, so $2,500 falls inside the mandate and any larger amount does not. A blocked proposal contributes nothing to the daily figure, because exposure records execution rather than intent; the actor is at $9,200 after the seventh row, not at $13,700. And the final row is refused at $10,200 against a $10,000 limit even though the transaction itself is well within the per-transaction ceiling, which is the case a per-transaction limit alone cannot catch.

Where more than one constraint fails, the decision reports a single Reason Code, chosen by a fixed evaluation order rather than by whichever check happens to run first: authority to act at all is established before the details of what is proposed. The same proposal therefore always yields the same code. The ordering is given in the specification.

Robinhood Chain as an environment of this kind

Robinhood Chain is publicly described as an execution environment oriented toward tokenized financial assets and onchain execution. This page treats it at that level of description and no further. Where an environment brings tokenized instruments, DeFi mechanisms, programmable accounts and automated actors into one place, it exhibits the convergence described above, and the four questions become live in it at once rather than one at a time.

An ecosystem of that shape is an application of the architecture, not a definition of it. It is a concrete setting in which the permission questions are unavoidable. Nothing in the mandate model, the credential model or the Reason Code registry is derived from any particular chain.

PASS is an independent protocol. It is not affiliated with, endorsed by or sponsored by Robinhood or any of its subsidiaries. Nothing on this page describes that company's design decisions, roadmap, participants or intentions, and nothing here should be read as a statement about them. See the disclaimer.

Where environment knowledge lives

The architecture is arranged so that environment-specific knowledge is confined to one layer.

PASSPORTS | MANDATES | POLICIES    <- environment
            |                         independent
            v
        PREFLIGHT
            |
            v
        ADAPTERS                   <- environment
        |       |                     specific
        v       v
   VENUE A    VENUE B

Everything above the adapter line is written in terms of actors, subjects, assets, actions and limits. Nothing in it names a chain. The adapter is where a raw call in a particular environment is decoded, normalized and resolved into the shape that policy can be evaluated against.

// Conceptual interface sketch: the shape preflight evaluates.
// An adapter produces this. Policy never reads raw calldata.
 
interface ExecutionIntent {
  actor: Address; // 0x81...29F
  subject: Address; // the account the actor acts for
  action: Action; // BUY | SELL | TRANSFER | BRIDGE
  asset: AssetRef; // AAPL, NVDA
  notionalUsd: bigint; // normalized for limit evaluation
  venue: VenueRef; // resolved by the adapter, not the caller
  chainId: number; // the environment, named only here
}

Supporting an additional environment means writing adapters for its venues. The mandate language does not change, the credential model does not change, and the Reason Codes do not change. A mandate expressing a $2,500 transaction ceiling and a STOCK_TOKEN_ELIGIBLE requirement expresses the same authority wherever it is evaluated, and a decision carries the same meaning to whoever reads it. A permission layer enforceable in only one environment would fail at precisely the boundary where an actor moves value out of it.

What this does not change

PASS constrains authorization risk. It does not remove market risk, smart-contract risk, oracle risk or governance risk, and it makes no assertion about the solvency or correctness of any venue. A decision of AUTHORIZED states that a proposed execution falls within the authority granted to that actor for that subject. It is not a statement that the trade is sound, the price is fair, or the counterparty is safe. Those judgements remain with whoever granted the mandate.

What a decision does state is narrow and checkable: at the moment of evaluation, this actor held this authority, for this subject, under these constraints, and the proposed execution fell inside them. That statement means the same thing in every environment where the architecture is applied, which is the property that makes a permission layer worth separating from the venues it evaluates.