> 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/middleware-not-executor.md). # Middleware, Not Executor ## Middleware, Not Executor RWAPACT is a decision and risk middleware layer. It sits between an autonomous agent that proposes a trade and the execution layer that carries out an authorized trade. The boundary is deliberate. RWAPACT evaluates whether a trade should reach execution. It does not perform the trade itself. ``` Agent | v RWAPACT | v Execution Layer ``` Each layer has a separate responsibility. Keeping those responsibilities distinct prevents technical executability from being treated as authorization. ### Roles in the trade path #### Agent The agent produces or submits a trade intent. It represents the autonomous decision-making system that may use strategy, market data, or delegated instructions to determine an action. Generating an intent does not give the agent unconditional execution authority. A valid proposed action must still pass RWAPACT's decision conditions before it can continue to execution. #### RWAPACT RWAPACT evaluates the trade intent against the conditions required for authorization. It evaluates RWA-specific risk conditions, validates session context, checks policy constraints, and evaluates gas and execution conditions. The protocol determines whether execution should be authorized. It records the resulting approval or rejection through KAR, the Attestation Registry. These checks form one decision gate, not a set of optional signals for the execution layer to interpret. #### Execution layer The execution layer performs the authorized trade. It remains responsible for transaction execution after RWAPACT has produced an approval. The protocol design identifies a DEX, MCP middleware or server, and a Robinhood API proxy as possible execution paths. These examples describe where the decision layer may sit. They do not state that each path is deployed or available as an integration. | Layer | Primary question | | --------------- | ------------------------------------------------ | | Agent | What trade do I want to make? | | RWAPACT | Should this trade be allowed to reach execution? | | Execution layer | How should the authorized trade be executed? | ### Execution validity and execution authorization Execution validity asks whether a transaction can be carried out. It can include valid parameters, sufficient balance, a valid signature, and a valid route for execution. Execution authorization asks whether that otherwise valid action should proceed under the current decision conditions. RWAPACT adds this question before the trade reaches the execution layer. Consider an agent submitting a technically valid trade for a tokenized stock. The request may have valid parameters, sufficient balance, a valid signature, and an available execution route. RWAPACT may still reject it when the RWA risk score exceeds the configured threshold, the agent session is outside its permitted scope, the requested amount exceeds policy limits, or gas conditions are not sufficiently optimized. The protocol does not replace wallet authorization or transaction validation. It adds a decision boundary that evaluates conditions those mechanisms do not necessarily address. ### Keeping risk logic separate from execution logic Execution infrastructure is concerned with carrying out transactions. Its path may determine routing and transaction handling. RWAPACT is concerned with the prior decision: whether this agent, asset, amount, and execution context satisfy the conditions required for authorization. Separating these functions gives the risk and policy decision a defined place before execution. It also avoids making an execution venue responsible for the full authorization context of an autonomous RWA trade. The decision gate combines the distinct conditions evaluated by the Five-Layer Pact: ``` Can_Trade = KRO risk below threshold AND KSO session active and in scope AND KPV policy allows asset and amount AND KGR gas conditions are optimized If true: Authorize execution Record approval through KAR If false: Reject with reason code Record rejection through KAR ``` This is a conceptual decision model, not implementation code. It shows why a technically executable transaction can remain unauthorized. Each required condition contributes to the same decision result. ### Preserving execution-layer flexibility RWAPACT does not become the execution venue. That architectural boundary allows the protocol design to wrap different execution paths while keeping its role focused on decision-making. DEX execution, MCP-based execution, and Robinhood API-based execution are examples of paths that can sit beyond the middleware boundary. Each path may have different mechanics. RWAPACT's responsibility remains the same: authorize or reject the proposed trade before that path executes it. This is a modular architecture. The protocol can sit around existing execution infrastructure rather than requiring the execution stack to be rebuilt around it. The statement describes the intended protocol design. It does not claim broad compatibility or deployed integrations. ### Creating a clear authorization boundary The authorization path evaluates the conditions before execution: ``` Trade Intent -> Risk Check -> Session Check -> Policy Check -> Gas Check -> Attestation -> Authorization -> Execution ``` When a required condition fails, the outcome follows a different path: ``` Trade Intent -> Failed Check -> Rejection -> Reason Code -> Attestation ``` Rejection is a normal protocol outcome. It is not necessarily a system failure. It can be the intended result when the trade does not meet the risk, session, policy, or gas conditions required for authorization. KAR records both outcomes with relevant context. This preserves the distinction between an execution transaction and the decision that allowed or prevented that transaction. ### Decision layer and execution layer | Decision layer | Execution layer | | ----------------------------------------- | ---------------------------------- | | Determines whether a trade should proceed | Carries out the authorized trade | | Evaluates context and constraints | Handles transaction execution | | Can reject the trade | Executes after authorization | | Produces an attested decision | Produces the execution transaction | The separation supports a clear protocol boundary. RWAPACT does not execute trades itself. It does not replace a DEX, a wallet, or the autonomous agent. It also does not guarantee profitable execution, compliance, or that every transaction is safe. RWAPACT is a decision and risk middleware layer. Its purpose is to evaluate whether a proposed autonomous RWA trade meets the required conditions before execution authorization is granted. Once the protocol is separated from the execution layer, the next design question is whether it must be tied to a specific autonomous agent framework. The next principle, Agent-Agnostic, addresses that boundary. --- # 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/middleware-not-executor.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.