> 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/use-cases/risk-blocked-trades.md). # Risk-Blocked Trades ## Risk-Blocked Trades An autonomous agent wants to buy an RWA token, but the underlying oracle has not updated for several hours. The agent may still see an executable on-chain market. However, the reference price used to evaluate the RWA may no longer reflect current market conditions. The blockchain transaction can be valid while the trade remains unsafe. This is the decision gap that RWAPACT addresses. The Pact evaluates whether execution should be permitted, not merely whether a transaction can be submitted. ### Stale oracle scenario The following example uses the stale-oracle scenario from the RWAPACT specification. 1. The agent submits a trade intent. 2. KRO checks the oracle condition. 3. KRO determines that the oracle is stale. 4. KRO assigns a risk score of `85`. 5. The score falls in the **Critical** tier. 6. RWAPACT rejects the trade with a reason such as `ORACLE_STALE`. 7. KAR records the rejection context. The attestation can preserve the agent and session context, risk score, policy version, rejection reason, and timestamp. Because the trade was not authorized, no execution transaction is associated with the rejected request. The agent receives the rejection context. It may retry later after the oracle condition is resolved. RWAPACT does not automatically retry the trade. ### Policy-Blocked Trade A trade can be blocked even when market conditions are acceptable. An agent submits a trade that exceeds the configured maximum trade size. KRO may assess market risk as acceptable. KSO may confirm that the session is active and within scope. KPV still rejects the request because the amount violates the active policy. This shows that risk assessment, session authority, and policy enforcement remain separate requirements. ### Why Rejection Is a Feature RWAPACT is not designed to maximize the number of executed trades. Its role is to decide whether an autonomous trade should execute under the configured risk, session, policy, and execution conditions. A rejected trade is a successful protocol outcome when the Pact prevents an unsafe or unauthorized action. The reason code gives the agent context to reassess its next action. ``` Trade Intent -> Pact Evaluation -> Risk or Policy Condition Fails -> Reject -> Return Reason Code -> Record Attestation -> Agent Can Reassess Later ``` *** --- # 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/use-cases/risk-blocked-trades.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.