> 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/the-five-layer-pact.md). # The Five-Layer Pact How KRO, KSO, KPV, KGR, and KAR work together as RWAPACT's integrated decision gate before RWA trade execution. ## The Five-Layer Pact A trade intent entering RWAPACT is not forwarded directly to the execution layer. It passes through a coordinated set of checks that evaluate different dimensions of whether the trade should proceed. This mechanism is the Five-Layer Pact. KRO, KSO, KPV, KGR, and KAR form one integrated decision gate before RWA trade execution. Every trade must pass the required decision layers before execution authorization is granted. ``` Agent -> Trade Intent -> KRO -> KSO -> KPV -> KGR -> KAR -> Execution Authorization -> Execution ``` Each layer contributes a distinct part of the decision context. Risk conditions do not establish agent authority. A valid session does not override policy. An allowed asset and amount do not make execution conditions acceptable on their own. The Pact evaluates these requirements together, then records the resulting decision. ### KRO, Risk Oracle KRO assesses RWA-specific risk for every trade before execution. Its purpose is to provide the risk context needed to determine whether the proposed action remains within an acceptable threshold. The risk evaluation considers oracle staleness, price deviation, liquidity depth, slippage estimate, market hours, compliance freeze, concentration, and volatility. These conditions reflect risks that can affect tokenized real-world assets, including tokenized stocks. KRO expresses the assessment as a score from 0 to 100: | Score range | Risk tier | | ----------- | --------- | | 0 to 20 | Safe | | 21 to 50 | Caution | | 51 to 80 | Risky | | 81 to 100 | Critical | A score of 0 represents no risk. A score of 100 represents critical risk. The Pact uses the score as an input to the authorization decision, subject to the threshold defined by the applicable policy. KRO does not authorize a trade by itself. Its role is to assess the risk condition that KPV and the broader decision gate use. The dedicated Risk Oracle section describes this evaluation in greater detail. ### KSO, Session Oracle KSO validates that the agent operates within an active, authorized session. A trade can be valid in isolation while remaining outside the authority delegated to the agent at that moment. KSO evaluates that authority in the context of the current session. A session includes a session ID, agent ID, owner, start time, end time, budget, spent amount, asset scope, maximum trade size, and status. These properties define the scope in which the agent may act. Before a trade proceeds, KSO checks that: * The session exists, is active, and has not been revoked. * The current time is within the session window. * The agent identity matches the session. * Cumulative spending remains within the budget. * The asset is in scope and the amount is within the maximum trade size. KSO therefore connects an individual trade intent to the authorization that governs the agent. It does not determine RWA risk or policy compliance. It verifies that the acting agent has the required authority for this trade now. ### KPV, Policy Vault KPV enforces configurable risk policies for an agent, owner, and asset. Every trade is evaluated against the active policy before authorization. Policy parameters can define allowed assets, maximum trade size, daily limit, maximum concentration, maximum slippage, oracle freshness requirements, minimum liquidity, market-hours permission, and a maximum KRO risk score. The policy provides the rules against which the trade conditions are evaluated. When a policy parameter is violated, the Pact rejects the trade with a specific reason code. This makes the policy outcome explicit rather than leaving the execution layer to infer why authorization did not occur. Policies are versioned. KAR includes the policy version in the attestation, connecting each decision to the policy context active at the time. KPV does not replace KRO or KSO. It applies the configured policy to the risk, session, asset, amount, and trade conditions that matter for authorization. ### KGR, Gas Router KGR evaluates gas cost and execution conditions for agent transactions. It treats these conditions as part of the decision context, not as a concern deferred until after a trade is approved. The protocol design identifies gas price monitoring, delay windows, batch execution, alternative route comparison, and L2 fallback where available as optimization strategies. These strategies inform whether the gas and execution conditions satisfy the requirements for the proposed action. KGR does not guarantee savings or act as a universal execution router. Its role within the Pact is narrower: evaluate whether the available execution conditions are sufficiently optimized before authorization. ### KAR, Attestation Registry KAR records the decision and its relevant context. It closes the decision loop by preserving what the Pact decided for a trade and the conditions associated with that outcome. An attestation can include an attestation ID, agent ID, session ID, asset, amount, risk score, policy version, gas route hash, approval status, rejection reason, timestamp, and the execution transaction hash after execution. This record preserves the decision context for both approvals and rejections. It does not itself decide whether a trade is safe. Nor does attestation automatically guarantee compliance or dispute resolution. KAR records the result produced by the decision gate. The specification also defines ERC-8273 compatibility for the attestation model. The dedicated Attestation Registry section covers the component in more detail. ### One coordinated decision gate The layers are intentionally complementary. Together, they form the Pact decision boundary around a proposed autonomous RWA trade. | Layer | Question | | ----- | --------------------------------------------------- | | KRO | Is the trade within acceptable RWA risk conditions? | | KSO | Is the agent authorized to act in this session? | | KPV | Does the trade comply with policy? | | KGR | Are gas and execution conditions acceptable? | | KAR | What decision was made and under what context? | KRO does not replace KSO. KSO does not replace KPV. KPV does not replace KGR. KAR does not independently decide whether a trade should be authorized. Each layer has a defined responsibility, and the resulting decision depends on their combined role. ``` Agent submits trade intent -> KRO evaluates risk -> KSO validates session -> KPV checks policy -> KGR evaluates gas conditions -> KAR records the decision -> Approved: execution -> Rejected: reason code + attestation ``` The Five-Layer Pact defines the components involved in the decision. [Pact Decision Logic](/whitepaper/the-rwapact-protocol/pact-decision-logic.md) explains how their outputs collectively result in authorization or rejection. --- # 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/the-five-layer-pact.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.