> For the complete documentation index, see [llms.txt](https://rwapact.gitbook.io/whitepaper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rwapact.gitbook.io/whitepaper/the-rwapact-protocol/protocol-overview.md). # Protocol Overview ## Protocol Overview RWAPACT is an integrated on-chain risk middleware for autonomous agent trading of Real-World Assets, or RWAs, on Robinhood Chain. At the protocol level, it creates a decision boundary between an agent's proposed trade and the system that carries out that trade. The boundary has a defined responsibility. The agent proposes the trade. RWAPACT evaluates the trade. The execution layer executes the trade only after authorization. This separation matters because a trade intent is not an authorization decision. An agent may form an intent from its strategy, market data, or delegated instructions. An execution layer may be able to route that intent. Neither role alone determines whether the action meets the risk, session, policy, and execution conditions required at that moment. RWAPACT evaluates those conditions before the trade reaches execution. It does not execute trades. It decides whether a trade should execute. ### Middleware between intent and execution In this architecture, middleware is the protocol layer that receives or evaluates a trade intent before it reaches an execution path. It is not a venue, wallet, trading strategy, or autonomous agent. Its purpose is to apply the required decision checks and produce an authorization outcome. The protocol therefore sits between two distinct responsibilities: * The **agent** determines and submits a trade intent. * **RWAPACT** evaluates that intent against its decision conditions. * The **execution layer** carries out an approved trade through its own execution path. This boundary prevents execution capability from being treated as unconditional authorization. It also keeps the agent's strategy separate from the protocol's enforcement role. RWAPACT does not replace an agent's reasoning. It evaluates whether the resulting action is permitted to proceed. {% hint style="info" %} Execution answers how a trade is carried out. RWAPACT determines whether the trade should reach execution at all. {% endhint %} The same separation applies when an action is rejected. A rejection does not represent an incomplete execution attempt. It is a completed protocol decision: the required conditions were not satisfied, so the trade is not authorized to enter the execution layer. ### The five-layer risk gate RWAPACT implements a five-layer risk gate. Each layer addresses a different condition that can affect whether an autonomous RWA trade should proceed. Together, the layers form one decision boundary before execution authorization. KRO, the Risk Oracle, evaluates RWA-specific risk conditions. KSO, the Session Oracle, validates that the agent operates within an active, authorized session. KPV, the Policy Vault, checks the requested asset, amount, and trade conditions against configured policy. KGR, the Gas Router, evaluates gas and execution conditions. It determines whether the execution path is sufficiently optimized. KAR, the Attestation Registry, records the resulting decision and its relevant context as an on-chain attestation. These components do not act as independent approvals that an execution layer can selectively interpret. They contribute to a single decision gate. A favorable result in one layer does not override a failed requirement in another. For example, acceptable RWA risk does not establish session authority. A valid session does not permit an asset or amount that policy disallows. The protocol flow is conceptual. It shows how trade intent moves through the decision boundary. It does not define contract interfaces, data structures, or component implementation details. ``` Agent | v Trade Intent | v KRO: Risk Evaluation | v KSO: Session Validation | v KPV: Policy Validation | v KGR: Gas and Execution Conditions | v KAR: Decision Attestation | +--> Approved: Execution | +--> Rejected: Reason Code + Attestation ``` The sequence represents the protocol boundary, not a replacement execution stack. An approved outcome authorizes the trade to continue to execution. A rejected outcome stops the trade before execution and records the reason through KAR. | Layer | Primary responsibility | Decision question | | ----- | ------------------------------ | -------------------------------------------------- | | KRO | RWA risk evaluation | Is the trade within acceptable risk conditions? | | KSO | Session validation | Is this agent authorized to act in this session? | | KPV | Policy enforcement | Does the trade comply with configured policy? | | KGR | Gas and execution optimization | Are execution conditions acceptable and optimized? | | KAR | Attestation | What decision was made and under what context? | The Five-Layer Pact section examines the individual components. Here, the important point is their combined role: they make authorization depend on the complete decision context rather than on one signal. ### Decision model The core protocol logic can be expressed as a conjunction of required conditions: ``` Can_Trade = risk below threshold AND session active and in scope AND policy allows asset and amount AND gas conditions are optimized ``` When these conditions are satisfied, RWAPACT authorizes execution and KAR attests the decision. The authorization permits the trade to proceed into the configured execution path. It does not mean RWAPACT executes the trade itself. When any required condition is not satisfied, RWAPACT rejects execution. KAR records the rejection reason and relevant decision context. This makes rejection a first-class protocol outcome. The protocol is designed to produce a clear decision in both cases, rather than treating failure as an incidental byproduct of transaction execution. The model is intentionally strict about the boundary. A trade does not become authorized because it is technically executable. It becomes authorized only after the conditions that govern the trade have been evaluated together. ### Design principles The protocol architecture follows five principles that define its role in the stack. #### Middleware, not executor RWAPACT evaluates and authorizes trade intents. It does not route orders, settle trades, or serve as the execution venue. This keeps the decision function separate from execution mechanics and assigns each part of the stack a clear responsibility. #### Agent-agnostic RWAPACT is designed to sit behind different autonomous agent systems. It does not require a specific agent framework to perform its decision role. The protocol evaluates the trade intent and its authorization context, regardless of how the agent produced that intent. #### RWA-specific The risk gate is designed for autonomous trading of RWAs. KRO supplies the RWA-specific risk evaluation that forms part of the authorization decision. The protocol treats this risk context as a condition of trade authorization, not as an optional signal outside the execution path. #### On-chain enforceable The decision gate is designed to enforce its required conditions on-chain before execution authorization. Risk, session, policy, and gas conditions are part of the protocol decision path. They are not merely recommendations for an agent or operator to apply later. #### Attested Each authorization or rejection is recorded through KAR with its relevant context. Attestation gives the protocol a defined on-chain record of the decision. It captures the authorization outcome at the point where an intent either reaches execution or is stopped. ### Execution paths remain separate RWAPACT is designed to remain independent of a single execution environment. Its decision boundary can wrap different execution paths, including a DEX, MCP middleware, or a Robinhood API proxy. These examples describe the protocol's intended architectural position. They do not imply that every path is deployed, integrated, or production-ready. Execution-layer agnosticism keeps the protocol focused on authorization. A given execution path can change its routing, interface, or implementation without changing the fundamental decision question. RWAPACT evaluates whether the trade should proceed before that path carries it out. This does not make the protocol an execution-only stack with additional checks. Execution-only systems focus on carrying out a transaction once it is submitted. RWAPACT adds a gate that combines risk evaluation, session validation, policy enforcement, gas conditions, and attestation before the transaction reaches that stage. The distinction is not that any one of these functions is new on its own. The protocol brings them together as one enforceable decision boundary for autonomous RWA trading. The protocol does not replace the execution stack. It adds a decision boundary around it. With the boundary and five-layer structure established, [Core Design Principles](/whitepaper/the-rwapact-protocol/core-design-principles.md) examines the principles that govern RWAPACT's behavior. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://rwapact.gitbook.io/whitepaper/the-rwapact-protocol/protocol-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.