> 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/security-and-risk-model/attested-auditability.md). # Attested Auditability ## Attested Auditability For autonomous trading, knowing that a transaction happened is not enough. A useful audit record also shows the conditions under which RWAPACT allowed or rejected the trade. The RWAPACT specification identifies an attestation gap. Systems may lack a permanent record of risk checks, policy decisions, session context, and gas optimization. KAR, the Attestation Registry, addresses this gap by recording the decision context on-chain. KAR records what the Pact decided. It does not calculate risk or authorize a trade by itself. KRO supplies risk context. KSO supplies session context. KPV supplies policy state. KGR supplies gas-route context. ### Attestation fields | Field | Purpose | | ---------------------------- | ----------------------------------------------------------------- | | Attestation ID | Identifies the decision record. | | Agent ID | Identifies the agent that submitted the trade intent. | | Session ID | Identifies the delegated session evaluated by KSO. | | Asset | Records the requested RWA asset. | | Amount | Records the requested trade amount. | | Risk score | Preserves KRO's risk assessment for the request. | | Policy version | Identifies the active KPV policy used for the decision. | | Gas route hash | References the gas route evaluated by KGR. | | Approval or rejection status | Records whether RWAPACT authorized execution. | | Rejection reason | Identifies the failed condition when the decision is rejected. | | Timestamp | Records when the decision was made. | | Execution transaction hash | Links the record to execution after an authorized trade executes. | The execution transaction hash is associated after execution when applicable. A rejected trade has no execution transaction because it was not authorized. ### Approved Trade When all required Pact checks pass, RWAPACT authorizes execution. KAR records the approval context. The attestation preserves the risk score, session ID, policy version, gas route information, and related decision context. The execution transaction hash can be associated with the attestation after execution. KAR therefore connects the authorization decision with the later execution reference. It does not perform the execution. ### Rejected Trade When a required Pact condition fails, RWAPACT rejects the trade. KAR records the rejection and preserves the reason. The decision can include the associated session and policy context. This record provides evidence of why the trade was not authorized. Rejected requests remain meaningful protocol data even though no transaction executes. ### Why Policy Version Matters KPV policies are versioned. KAR includes the policy version associated with each decision. This lets later analysis determine which policy configuration governed the trade at that time. The version forms part of the record for both approvals and rejections. ### ERC-8273 Compatibility The RWAPACT specification states that KAR implements an ERC-8273-compatible interface. This supports interoperability with other attestation-based systems while adding an RWA-specific attestation schema. The compatibility statement is limited to the specification. It does not claim full ERC-8273 compliance beyond that statement. ### Illustrative attestation context The following is an illustrative representation of attestation context. It is not a literal production transaction object. ``` Agent: ERC-8004 agent identity Session: Active delegated session Asset: Tokenized stock Amount: Requested trade amount Risk Score: KRO result Policy Version: Active KPV version Gas Route: KGR route hash Decision: Approved or rejected Rejection Reason: Populated when rejected Timestamp: Decision timestamp Execution TX: Linked after execution when applicable ``` The representation shows how a single record links the Pact's decision inputs. It also distinguishes an authorization outcome from the eventual execution reference. ### Auditability Without Successful Execution A rejected trade is also meaningful protocol data. An agent may repeatedly attempt a trade while oracle data remains stale. KAR can preserve those rejection decisions rather than treating them as invisible failed requests. The decision record can support: * Post-trade auditing. * Decision analysis. * Dispute analysis. * Future reputation systems. KAR does not automatically create reputation scores or resolve disputes. It provides the underlying decision record for systems that may use it. ### Attestation as the Final Pact Layer Attestation is not simply an afterthought after execution. It is the permanent record of what RWAPACT decided, under which session and policy context, and whether execution was authorized. KAR closes the Pact by preserving the result from KRO, KSO, KPV, and KGR. This makes the decision inspectable whether the trade was approved, rejected, executed, or never sent to execution. *** --- # 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/security-and-risk-model/attested-auditability.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.