> 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/pact-execution/authorization-and-rejection.md). # Authorization and Rejection ## Authorization and Rejection Authorization is the final Pact decision. It is not a single check or an execution action. Before this point, an Agent has submitted a Trade Intent for evaluation. KRO, KSO, KPV, and KGR each contribute a required result. The Pact combines those results to decide whether the Trade Intent may proceed to the Execution Layer. ``` Trade Intent -> KRO Risk Oracle -> KSO Session Oracle -> KPV Policy Vault -> KGR Gas Router -> Authorization or Rejection ``` RWAPACT authorizes execution. It does not perform the execution itself. ### The final Pact decision Each Pact layer answers a different question: * **Risk evaluation:** Is the proposed trade sufficiently safe? * **Session validation:** Is the Agent authorized within the active Session? * **Policy enforcement:** Does the trade follow the configured rules? * **Final authorization:** Have all required conditions passed? The final decision requires every condition to pass: ``` Can_Trade = KRO risk below threshold AND KSO session active and within scope AND KPV policy allows asset and amount AND KGR gas optimized ``` KRO provides the Risk Score used for the risk condition. KSO validates that the Session is active and within scope. KPV checks the requested asset and amount against the Policy Version. KGR determines whether an acceptable, optimized gas path is available. No individual layer can authorize a trade on its own. ### When a trade is authorized When `Can_Trade` is true, the Pact authorizes the Trade Intent to proceed to the Execution Layer. KAR records the approval and the evaluation context as an Attestation. The Execution Layer may then process the trade. Its execution is separate from the Pact decision. ``` All Pact conditions pass -> Authorization -> KAR approval Attestation -> Execution Layer ``` Authorization means the trade may proceed. It does not mean execution has already occurred. ### When a trade is rejected When any required condition fails, the Pact rejects the Trade Intent. The rejection identifies the failed condition through a specific reason or code. KAR records the Rejection and its relevant context. This gives the Agent feedback about why execution was not authorized. For example, an Agent may request an RWA token purchase while its oracle is stale. KRO detects the stale oracle and returns a critical risk result. The Pact rejects the trade with a reason such as `ORACLE_STALE`, and KAR records the rejection context. ``` Any Pact condition fails -> Rejection with reason -> KAR rejection Attestation -> No execution ``` ### What happens after the decision The Pact answers one question: **Should this trade be allowed to execute?** KAR answers the next question: **What did RWAPACT evaluate and decide?** It permanently records the approval or Rejection, together with the Pact context. Read [Attestation](/whitepaper/pact-execution/attestation.md) to see how that record links the decision to execution when applicable. *** --- # 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/pact-execution/authorization-and-rejection.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.