> 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/rwa-arbitrage.md).

# RWA Arbitrage

Shows how RWAPACT evaluates risk, session authority, policy constraints, and gas efficiency when an autonomous agent executes an RWA arbitrage strategy.

## RWA Arbitrage

An agent detects a price difference between two tokenized RWA liquidity pools. It wants to execute both legs of an arbitrage trade.

The agent submits the arbitrage trade intent to RWAPACT. Arbitrage introduces additional constraints because both legs must be considered together. An apparent spread does not establish that the opportunity is current, authorized, or executable within policy.

### 1. KRO, Risk Oracle

KRO evaluates whether the observed difference reflects current market conditions. It checks for oracle staleness, abnormal price deviation, insufficient liquidity, excessive slippage, and other RWA-specific risk conditions.

This prevents the agent from treating every apparent price difference as a valid arbitrage opportunity. A stale reference price can create a misleading spread. Shallow liquidity can make the proposed size unexecutable under acceptable conditions.

### 2. KSO, Session Oracle

KSO verifies that the agent's session remains active. It confirms that the budget can cover both legs and that the required assets are within session scope.

Each trade must also remain within the session's individual limits. A session that covers one leg does not automatically authorize the complete arbitrage request.

### 3. KPV, Policy Vault

KPV applies the active policy to the arbitrage intent. It checks whether trading the requested assets is permitted under the policy.

The evaluation includes maximum trade size, concentration, slippage requirements, the permitted risk threshold, and other configured constraints. KPV evaluates compliance with those constraints. It does not estimate profitability.

### 4. KGR, Gas Router

Execution cost can materially affect an arbitrage attempt. KGR evaluates whether the two legs can use an acceptable and efficient execution path.

Where supported by the protocol design, KGR can evaluate batching both legs in one transaction. It can also evaluate route conditions and delay windows. These checks do not guarantee a profit or gas savings.

### 5. KAR, Attestation Registry

KAR records the resulting decision context. The attestation provides a durable record of the risk, session, policy, gas, and decision context associated with the arbitrage attempt.

For an approved request, the record can later associate the execution transaction hash. For a rejected request, it preserves the reason that prevented authorization.

### Outcomes

#### Approved

All required conditions pass. RWAPACT authorizes the arbitrage execution path, and KAR records the decision context.

#### Rejected

One or more required conditions fail. RWAPACT rejects the trade and records the reason through KAR. Neither leg receives authorization from the Pact.

### Example: apparent spread from stale data

The agent sees a large price difference between two RWA pools. KRO determines that the difference results from stale oracle data rather than a genuine market opportunity.

RWAPACT rejects the arbitrage attempt. This prevents the agent from executing against misleading pricing information. The rejection context can identify the stale-oracle condition for later review.

### Why RWA Arbitrage Needs a Decision Layer

Arbitrage agents operate quickly. They may interpret market differences as opportunities before confirming that those differences are trustworthy, authorized, and executable within configured risk boundaries.

RWAPACT applies those checks before execution. It separates a detected price difference from a trade the protocol is prepared to authorize.

***


---

# 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/rwa-arbitrage.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.