> 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/failure-handling.md).

# Failure Handling

Explains how RWAPACT handles failed Pact checks, rejects unsafe trades with specific reason codes, and preserves the decision context for later review.

## Failure Handling

RWAPACT does not authorize a trade unless the required Pact conditions pass. A failed condition produces a rejection before the execution request is authorized.

The core decision model is:

```
Can_Trade =
  KRO risk below threshold
  AND KSO session active and within scope
  AND KPV policy allows asset and amount
  AND KGR gas optimized

If true:
  Authorize execution
  Record approved attestation

If false:
  Reject with reason code
  Record rejected attestation
```

KRO evaluates RWA risk. KSO validates session authority. KPV applies trading policy. KGR evaluates gas route conditions. KAR records the approval or rejection context.

### Failure categories

The following conditions represent checks defined by the protocol. They are not an exhaustive reason-code registry.

| Failure condition           | Responsible layer | Result |
| --------------------------- | ----------------- | ------ |
| Oracle stale                | KRO               | Reject |
| Risk threshold exceeded     | KRO/KPV           | Reject |
| Session expired             | KSO               | Reject |
| Session revoked             | KSO               | Reject |
| Asset outside session scope | KSO               | Reject |
| Session budget exceeded     | KSO               | Reject |
| Maximum trade size exceeded | KPV               | Reject |
| Policy restriction violated | KPV               | Reject |
| Insufficient liquidity      | KRO/KPV           | Reject |
| Excessive slippage          | KRO/KPV           | Reject |
| Compliance freeze           | KRO               | Reject |

The responsible layer identifies the condition that cannot pass. Where KRO and KPV appear together, KRO supplies the current condition and KPV applies the configured policy boundary.

### Example: stale oracle

An agent attempts to buy an RWA token while the oracle has not updated for several hours. KRO identifies stale data and produces a critical risk assessment.

RWAPACT rejects the trade with a reason such as `ORACLE_STALE`. KAR records the rejection context. The agent can retry after the underlying oracle condition is resolved.

### Rejection Is Not Execution Failure

A Pact rejection occurs before RWAPACT authorizes the execution request. It differs from a transaction reverting or an execution venue failing after authorization.

RWAPACT makes a decision about whether execution should be permitted. It does not execute the trade itself. A rejection means the required decision conditions were not satisfied.

```
Trade Intent
  -> Pact Checks
  -> Condition Fails
  -> Reject + Reason Code
  -> KAR Records Decision
```

This lifecycle has no execution step because the Pact did not authorize one.

### Deterministic Feedback for Agents

Autonomous systems need explicit failure information. A generic `transaction failed` response does not identify the next safe action.

A Pact reason code identifies the authorization condition that failed. An agent can distinguish an oracle condition from a session expiry. It can distinguish a policy size limit from a liquidity or slippage condition.

That context supports informed follow-up behavior. An agent may wait for an oracle update, submit a smaller amount, or stop the request. RWAPACT does not automatically repair failed trades or override restrictions.

### Fail closed at the decision boundary

Rejection is a normal protocol outcome. RWAPACT is designed to reject unsafe or unauthorized trades rather than force execution.

KAR preserves the decision context for later review. The rejection remains attributable to the evaluated trade, session, policy, risk conditions, and reason code.

***


---

# 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/failure-handling.md?ask=<question>&goal=<endgoal>
```

`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.