> 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/the-agent-trading-problem.md). # The Agent Trading Problem ## The Agent Trading Problem Autonomous agents can move from instruction to transaction without a person reviewing each action. An agent can interpret a strategy, identify an opportunity, create a trade intent, and pass that intent into on-chain execution infrastructure. This makes trading systems more capable. It also changes where trade decisions need to happen. The current stack already handles many execution responsibilities well. It can route an order, obtain a signature, submit a transaction, and settle the resulting action on-chain. Each component can perform its role correctly while the system still lacks a clear answer to a separate question: **Should this trade be executed under the current conditions?** This is the agent trading problem. A technically valid transaction is not necessarily an authorized or appropriate trade. Autonomous trading needs both the ability to execute an action and a way to govern the decision that permits it. ### A trade can be executable without being approved Consider a trade intent created by an agent. The intent specifies an action the agent wants to take, such as buying or selling an asset. The execution path can then determine how to reach a venue. A wallet can sign the transaction. The transaction can be accepted and processed by the blockchain. From an execution perspective, this flow works. The transaction is correctly formed, signed by an authorized key, and submitted through a valid route. None of those facts, by themselves, establish that the action should have been allowed to proceed. An agent may propose a trade that exceeds a user's intended limit. It may act outside an authorized session. It may select an asset that conflicts with the user's policy. The surrounding conditions may also differ from those assumed when the agent formed its intent. These cases do not mean that the transaction is malformed. They show that transaction validity and trade authorization are different concepts. A valid transaction establishes that the network can process the requested state change. Trade authorization establishes that the action is permitted within the authority, constraints, and conditions set for the agent. The first is necessary for execution. The second is necessary for governed autonomous trading. ### The roles in an execution-oriented stack The systems involved in a trade each solve an important problem. Their responsibilities should remain distinct. #### The agent forms the intent The agent interprets its instructions or strategy and produces a trade intent. It may decide what to buy or sell and when to act. It can respond to signals continuously and create new intents without waiting for manual review. That autonomy is useful, but it should not make the agent the final authority on every proposed action. An intent represents what the agent wants to do. It does not, on its own, determine whether the action remains allowed when execution is attempted. #### The execution layer handles the mechanics The execution layer is responsible for making a trade possible. Depending on the environment, this path can use a DEX, an MCP server, or an API-based execution route. It finds or applies the mechanism that carries an approved trade toward execution. This responsibility is different from evaluating the full decision context. Execution infrastructure is designed to route and submit transactions. It does not need to become the source of every policy, session, or risk decision that governs an autonomous agent. #### The wallet authorizes the transaction The wallet provides authorization through signing. A signature proves that an authorized key approved a transaction. This is a critical control in the transaction flow. Signing is not the same as evaluating every condition associated with the trade. A signature does not necessarily establish that the action is within a configured budget, within the intended session, or aligned with a user's policy. That is not a weakness in wallets. A wallet addresses key authorization. Autonomous trade governance requires additional decision context. ### The missing decision context An autonomous agent needs explicit boundaries around what it can do. Those boundaries must apply when an intent becomes an execution attempt, not only when the agent first receives its instructions. Relevant questions include: * Is the agent operating within an authorized session? * Is the asset and proposed amount allowed by the user's policy? * Are the current conditions acceptable for this action? These are not routing or signing questions. They are authorization and risk questions. They determine whether a trade should move forward at a particular point in time. The distinction can be expressed simply: **Execution infrastructure answers how a transaction gets executed. A decision layer answers whether that transaction should be allowed to execute.** For autonomous systems, the decision cannot remain an implicit assumption. It needs to be evaluated as part of the path between agent intent and execution. Otherwise, a system can faithfully execute an action without confirming that the action still matches its intended authority and constraints. This does not require treating every trade as suspect or preventing agents from acting. It establishes a control point for deciding when their actions remain within the bounds under which they were intended to operate. ### Autonomy changes the risk boundary Manual trading includes a natural review step. A person can inspect an asset, amount, timing, and market context before signing. That review may be brief, but it is part of the decision process. With an autonomous agent, that review can disappear from individual transactions. The agent may generate and submit actions repeatedly according to its logic. It may react to external inputs faster than a person can inspect each proposed trade. The risk boundary therefore shifts. The question is not only whether an authorized key can sign a transaction. It is also whether the agent is acting within the scope the user intended. The system needs machine-enforceable decision checks before execution when human review is no longer present at every step. This is especially important when an agent interacts with financial infrastructure across separate systems. The agent, wallet, and execution layer can each be operating as designed. Without a dedicated decision step, no component necessarily evaluates the full context of the proposed trade. RWAPACT is designed to address this gap as on-chain risk middleware. It sits between the agent and the execution layer, where it can evaluate whether a trade should proceed. It does not replace the agent, wallet, or execution venue. It adds the decision responsibility that those roles do not inherently cover. ### From agent actions to RWA decisions The decision problem becomes more significant when the assets are tokenized Real-World Assets. Their trading context can include conditions that basic transaction validity and execution logic do not capture. The next page, [The RWA Risk Gap](/whitepaper/introduction/the-rwa-risk-gap.md), examines why those conditions matter. It explains the additional context that can shape whether an autonomous RWA trade should be allowed to proceed. --- # 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/the-agent-trading-problem.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.