> 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/core-design-principles.md). # Core Design Principles The five architectural principles that define how RWAPACT evaluates autonomous RWA trades before they reach execution. ## Core Design Principles RWAPACT is defined by more than its five decision layers. Its architecture also depends on boundaries that determine where the protocol sits, what it evaluates, how it enforces conditions, and how it records decisions. Those boundaries guide the protocol's behavior before a proposed RWA trade reaches execution. They separate agent intent from authorization, focus risk evaluation on RWA conditions, and preserve an explicit record of the resulting decision. | Principle | Architectural meaning | | ------------------------ | ------------------------------------------------------------ | | Middleware, not executor | Evaluates authorization without becoming the execution venue | | Agent-agnostic | Separates decision logic from the agent framework | | RWA-specific | Evaluates risks specific to tokenized real-world assets | | On-chain enforceable | Makes decision conditions enforceable through protocol logic | | Attested | Records the decision and relevant context | Together, these principles determine where RWAPACT sits in the stack, how it interacts with autonomous agents, the type of risk it evaluates, where enforcement occurs, and how outcomes persist. ### Middleware, not executor RWAPACT sits between an agent and an execution layer. It receives or evaluates a proposed trade intent, applies the required decision conditions, and determines whether the trade is authorized to continue. It does not become another trading venue or execution engine. The execution layer remains responsible for carrying out an authorized trade. The agent remains responsible for producing the intent. **RWAPACT does not execute trades. RWAPACT decides whether a trade should execute.** This separation makes authorization an explicit protocol responsibility. The protocol can reject a trade before execution when its required risk, session, policy, or gas conditions are not satisfied. The next page examines this boundary in detail. ### Agent-agnostic RWAPACT is designed around the trade intent and its decision context, not around one autonomous agent framework. An agent may produce an intent from strategy, data, delegated instructions, or another decision process. RWAPACT evaluates whether that resulting intent is permitted to proceed. The protocol design can sit behind environments such as MCP, LangChain, ElizaOS, and custom agent systems. These are examples of agent environments that may generate trade intents. They do not indicate that every framework is integrated, deployed, or supported in a particular implementation. Agent agnosticism keeps the decision layer separate from the system that generated the action. Different agent architectures may differ in their models, tools, workflows, and strategies. The authorization question remains consistent: does this proposed trade satisfy the conditions that apply now? This boundary also avoids treating an agent's ability to formulate a valid intent as permission to execute it. Intent enters the decision gate. Authorization depends on the required protocol conditions. ### RWA-specific RWAPACT is designed for autonomous trading of tokenized real-world assets, particularly tokenized stocks. These assets can introduce risk conditions that do not reduce to basic transaction validity or a generic cryptocurrency price check. The protocol's RWA risk model accounts for conditions such as oracle staleness, market-hours mismatch, liquidity fragmentation, compliance-related freezes or blocks, and concentration risk. These conditions can affect whether a trade should be authorized even when the transaction itself is technically valid. For example, an asset's price data may be stale, or the relevant market may not be operating within expected hours. Liquidity can be fragmented across available paths. A policy or asset condition may also prevent action. Each condition belongs in the decision context for an autonomous RWA trade. The RWA-specific principle does not make every trade condition a risk oracle function. It establishes that risk evaluation is designed around the characteristics of tokenized real-world assets. KRO, the Risk Oracle, is the dedicated component for that evaluation in the Five-Layer Pact. ### On-chain enforceable An instruction to an agent is not the same as enforcement. An agent may be told not to trade outside a policy boundary, but that instruction alone does not create an authorization gate before execution. RWAPACT is designed to make its required decision conditions enforceable through protocol logic. The specification describes these checks as smart contract calls. The gate evaluates the required conditions before it authorizes execution, rather than leaving them as advisory guidance for an agent or operator. This principle applies to the protocol decision, not to a claim that every system involved in a trade is fully on-chain. Agents, data sources, and execution paths can have their own architectures. RWAPACT's role is to enforce the conditions that govern authorization at the decision boundary. The distinction is practical. A policy, session, or risk requirement has effect only when it participates in the path that determines whether execution is allowed. On-chain enforcement gives those requirements a defined place in that path. ### Attested RWAPACT does not only return an authorization outcome. KAR, the Attestation Registry, records the decision and its relevant context on-chain. This creates persistent decision history for approvals and rejections. The attested context can include the approval or rejection, risk score, session ID, gas path, policy version, and a rejection reason when applicable. These fields connect the outcome to the decision context that produced it. Attestation supports auditability of the protocol decision. It does not itself guarantee compliance, reputation, dispute resolution, or trade safety. Its architectural role is narrower: record what RWAPACT decided and the relevant context at that point. This record also treats rejected trades as meaningful outcomes. A rejected trade may be the intended result when a required condition fails. Recording that result preserves the decision boundary instead of reducing the outcome to an absent execution transaction. ### Principles as protocol boundaries The five principles establish the architectural boundaries of RWAPACT. The protocol evaluates autonomous RWA trade intents without becoming the agent or the execution venue. It applies RWA-aware conditions through enforceable decision logic, then records the resulting outcome through attestation. The most fundamental boundary separates deciding whether a trade should proceed from executing that trade. [Middleware, Not Executor](/whitepaper/the-rwapact-protocol/middleware-not-executor.md) examines how that separation shapes the protocol 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/the-rwapact-protocol/core-design-principles.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.