> 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/introduction.md). # Introduction ## Introduction Autonomous agents are starting to interact directly with financial infrastructure. They can interpret instructions, form trade intents, and initiate transactions through wallets and execution venues. This changes what it means to build trading infrastructure. When a user acts manually, judgement often occurs outside the transaction path. The user reviews the asset, timing, and conditions before signing. An autonomous agent compresses that process. It can move from instruction to transaction quickly, often across systems that each perform a narrow role. That capability creates a new requirement. Financial infrastructure must do more than make a transaction possible. It must help determine whether the proposed action should proceed. RWAPACT is an integrated on-chain risk middleware for autonomous trading of Real-World Assets on Robinhood Chain. It provides a decision layer between an agent and the execution layer. RWAPACT evaluates a trade intent before execution. It does not execute the trade itself. ### When execution is not the whole decision An agent can produce a trade intent. A wallet can authorize an action through a signature. An execution layer can route and submit a transaction. Together, these components make a trade operationally possible. They do not automatically answer whether that trade is appropriate at that moment. This distinction matters because execution and decision are different responsibilities. Execution concerns how an approved action reaches a venue. Decision concerns whether the action satisfies the conditions required before it reaches that venue. A system can be efficient at execution while lacking the context needed to govern a trade. For an autonomous agent, that gap becomes part of the transaction path. The agent needs a mechanism that can evaluate an intended action before execution begins. It needs to account for the conditions surrounding the intent, rather than treating a valid signature or routable transaction as a complete decision. The question is straightforward: **Should this trade happen at all?** That question is not answered by transaction submission alone. It requires a layer that can govern the decision before the execution layer receives it. The [The Agent Trading Problem](/whitepaper/introduction/the-agent-trading-problem.md) examines this gap in the execution-focused stack. ### Why Real-World Assets add context Tokenized Real-World Assets introduce considerations that extend beyond generic transaction execution. A trade can depend on market conditions that are not represented by its basic transaction structure. It can also depend on whether relevant external information remains current. For example, a proposed trade may require awareness of liquidity, price deviation, slippage, volatility, and oracle freshness. Market hours can affect whether an asset is actively tradable. Compliance-related restrictions and concentration can also shape whether an action is permitted under the intended conditions. These considerations are not a claim that every trade must use the same checks. They show why a simple ability to submit a transaction is incomplete for RWA trading. The decision must reflect the context in which the agent is acting. An autonomous system should not assume that a trade remains suitable just because it was suitable when the instruction was first formed. Conditions can change between intent and execution. The infrastructure around the agent needs a way to evaluate that change before an action proceeds. The [The RWA Risk Gap](/whitepaper/introduction/the-rwa-risk-gap.md) explores these considerations in detail. ### A layer for governed trade decisions RWAPACT is designed for the space between intent and execution. It receives the trade context needed for a decision and determines whether the trade can proceed through the defined process. This separates trade governance from the systems responsible for authorization and execution. The separation is deliberate. A wallet remains responsible for signing. An execution venue remains responsible for execution. RWAPACT provides the risk and decision layer before that execution occurs. This approach gives autonomous trading systems a clear control point. Instead of embedding every decision directly in an agent or relying on execution infrastructure to infer intent, a dedicated middleware layer can evaluate the proposed trade before it moves forward. RWAPACT does not eliminate risk or guarantee that a trade is safe. It establishes a structured place to evaluate a trade decision before execution. That is the role the protocol is designed to serve on Robinhood Chain. The next sections build this foundation step by step: * [The Agent Trading Problem](/whitepaper/introduction/the-agent-trading-problem.md) examines the limits of execution-focused systems. * [The RWA Risk Gap](/whitepaper/introduction/the-rwa-risk-gap.md) explains why RWA trading needs additional context. * [Why a Decision Layer Matters](/whitepaper/introduction/why-a-decision-layer-matters.md) defines the role of this missing layer. From there, [Introducing RWAPACT](/whitepaper/introduction/introducing-rwapact.md) introduces the protocol and its architecture. --- # 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/introduction.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.