> 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/introduction/introducing-rwapact.md). # Introducing RWAPACT ## Introducing RWAPACT [Why a Decision Layer Matters](/whitepaper/introduction/why-a-decision-layer-matters.md) established the need for a boundary between agent intent and execution. Autonomous RWA trading needs a place to evaluate the conditions that determine whether a proposed action should proceed. RWAPACT is designed to provide that boundary. RWAPACT is an integrated on-chain risk middleware for autonomous agent trading of Real-World Assets on Robinhood Chain. It sits between the agent and the execution layer. It evaluates a trade intent before execution is authorized. ``` Agent Intent | v RWAPACT Decision Layer | v Execution Layer ``` Its role is deliberately narrow and important. RWAPACT does not execute trades. RWAPACT decides whether a trade should execute. The protocol evaluates the relevant decision context before an action reaches the execution path. That context can include risk, agent authority, policy constraints, execution conditions, and the resulting record of the decision. > **RWAPACT sits between intent and execution.** > > The agent proposes the trade. RWAPACT evaluates whether it should proceed. The execution layer handles the trade. ### A decision and risk gate Autonomous agents can produce trade intents from strategy, data, or user-defined instructions. A wallet can sign a transaction. An execution layer can route that transaction through a venue, service, or API. Those functions make a trade possible. They do not necessarily establish that the trade should be authorized under current conditions. That decision can require information that crosses several responsibilities. RWAPACT creates an explicit gate for that decision. It receives a proposed trade and evaluates the conditions required before execution. An action proceeds only when the required conditions are acceptable. If a required condition fails, the action is not authorized. This approach separates decision-making from the mechanics of execution. RWAPACT does not replace the agent's reasoning or strategy. It does not take the role of the wallet. It does not become a DEX or another execution venue. Instead, it wraps the decision point around existing execution infrastructure. This preserves the responsibilities of the systems already involved in a trade while creating a defined authorization checkpoint. | RWAPACT is | RWAPACT is not | | ---------------------------------- | ------------------------------------------ | | On-chain risk middleware | A DEX | | A decision and authorization layer | A wallet | | RWA-aware | A trading strategy | | Agent-agnostic | An autonomous agent | | Execution-layer agnostic | A replacement for execution infrastructure | | Attested | An off-chain prompt or recommendation | These boundaries are architectural. They clarify which responsibility belongs to which part of the stack. The agent expresses intent. RWAPACT evaluates authorization. The execution layer carries out approved actions. ### The Five-Layer Pact RWAPACT evaluates a trade through five complementary layers. Together, they provide a high-level framework for deciding whether an autonomous RWA trade should proceed. **KRO, Risk Oracle** evaluates RWA-specific risk conditions. It provides risk context relevant to the proposed trade. **KSO, Session Oracle** validates whether the agent's current session is active and within its authorized scope. It connects a trade attempt to the authority granted to the agent. **KPV, Policy Vault** checks whether the asset, amount, and other policy constraints permit the action. It applies the defined rules that govern what the agent may do. **KGR, Gas Router** evaluates execution cost and gas conditions. It treats the conditions of execution as part of the broader trade decision. **KAR, Attestation Registry** records the resulting decision and relevant context on-chain. It provides an attested record of the authorization outcome. The five layers are not separate execution venues. They are decision functions that contribute to a single authorization result. Each addresses a different condition that can matter before an autonomous trade reaches execution. The model does not assume that one input is sufficient. A favorable risk condition alone does not establish that an agent session is valid. A valid session alone does not establish that an asset or amount is permitted. Policy approval alone does not establish that execution conditions are acceptable. RWAPACT evaluates these dimensions as parts of the same decision. The following flow provides the conceptual model: ``` Agent submits 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 recorded ``` The flow shows the order of the conceptual decision path. It does not describe internal contracts, data structures, or parameter definitions. Later sections explain the protocol design and each layer in detail. ### Authorization across multiple conditions An autonomous RWA trade can proceed only when the conditions required for authorization are satisfied. At a high level, this includes acceptable risk, a valid session, permitted policy conditions, and acceptable execution conditions. If any required condition fails, RWAPACT can reject the proposed action before it reaches the execution layer. Rejection is an intended protocol outcome. It makes the decision boundary explicit rather than treating an unsuitable action as an execution failure. The resulting decision is recorded through the attestation layer. This provides an on-chain record of the decision and its relevant context. The record does not replace the execution layer's responsibilities. It records the outcome of the authorization process that happens before execution. This is more than a simple risk check. Risk is one part of the decision, but trade authorization can also depend on agent scope, policy boundaries, permitted assets and amounts, and execution cost. RWAPACT integrates these dimensions into one middleware layer designed around autonomous RWA trading. The distinction is the integration and enforcement of multiple decision dimensions before execution. RWAPACT does not claim that risk, policies, sessions, gas conditions, or attestations are individually new concepts. It brings them together at the point where an autonomous intent becomes an authorized action. ### Designed around existing systems RWAPACT is agent-agnostic. It evaluates trade intents without requiring one specific agent framework. MCP, LangChain, ElizaOS, and custom agent systems are examples of environments that can produce such intents. This principle keeps the decision layer focused on the action and its authorization context. An agent can vary in its implementation, strategy, or source of instructions. The decision requirement remains the same: evaluate whether the proposed trade should proceed under the conditions that apply now. RWAPACT is also execution-layer agnostic. It is designed to sit in front of different execution environments rather than relying on a single venue. DEX execution, MCP middleware, and a Robinhood API proxy are examples of possible execution paths. This does not state that every example is deployed or integrated. It describes the intended architectural position of the protocol. The decision layer should not be tightly coupled to one execution environment. Keeping decision and execution separate allows execution infrastructure to retain its purpose. It also allows risk and policy logic to remain independent from a specific trading venue. RWAPACT can evaluate an action before execution without becoming responsible for executing the trade itself. ### From decision boundary to protocol design RWAPACT gives autonomous RWA trading a defined path from intent to authorized execution. The agent can propose an action without receiving unconditional authority to carry it out. The protocol evaluates the relevant conditions, authorizes or rejects the action, and records the decision before execution proceeds. This is the role RWAPACT is designed to fill: an on-chain risk middleware layer between autonomous agents and the systems that execute their trades. [The RWAPACT Protocol](/whitepaper/the-rwapact-protocol/protocol-overview.md) examines the architecture, design principles, and decision logic behind that model. --- # 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/introduction/introducing-rwapact.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.