> 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/tokenized-stock-trading.md).

# Tokenized Stock Trading

Shows how RWAPACT evaluates and authorizes an autonomous agent trading a tokenized stock through the five-layer Pact.

## Tokenized Stock Trading

An autonomous agent wants to buy `$500` of tokenized TSLA on Robinhood Chain. The agent does not send that request directly to the execution layer.

It submits a trade intent to RWAPACT. The intent passes through the Five-Layer Pact before execution can be authorized. This example illustrates the protocol flow. It does not describe a production transaction.

### 1. Trade Intent

The agent submits the proposed trade:

* **Asset:** tokenized TSLA
* **Amount:** `$500`
* **Intended execution path:** the proposed route to the execution layer

This is an intent to trade, not an authorized execution. RWAPACT first evaluates whether the requested action meets the required risk, authority, policy, and gas conditions.

### 2. KRO, Risk Oracle

KRO evaluates the RWA-specific context for the tokenized stock. The assessment includes oracle freshness, price deviation, liquidity, estimated slippage, market hours, compliance freeze status, concentration, and volatility.

The trade can continue only when the relevant conditions meet their configured thresholds. A valid transaction format does not establish that its RWA price context is current or safe.

### 3. KSO, Session Oracle

KSO validates the agent's delegated authority. It checks that the session is active, the current time is inside its window, and the remaining budget can cover the request.

KSO also confirms that tokenized TSLA is within the session scope. It checks that the `$500` amount is within the session's maximum trade size. A failed session check stops the trade before execution.

### 4. KPV, Policy Vault

KPV applies the active trading policy to the request. It checks that tokenized TSLA is allowed and that `$500` remains within policy limits.

KPV also evaluates configured concentration, slippage, liquidity, and risk-score constraints. KRO supplies the current risk assessment. KPV determines whether that assessment is acceptable under the active policy.

### 5. KGR, Gas Router

KGR evaluates the available execution path and gas conditions. Its role is to avoid unnecessary execution cost and identify an acceptable gas route.

KGR may compare available routes or apply a delayed condition where supported. It does not guarantee the cheapest transaction. Its result remains one required input to the Pact decision.

### 6. KAR, Attestation Registry

KAR records the decision context after the Pact reaches a result. The record can include:

* Agent ID and session ID
* Asset, amount, risk score, and policy version
* Gas route hash, approval status, and timestamp

When applicable, KAR can associate the execution transaction hash after execution. KAR records the decision. It does not execute the trade.

### Outcomes

If every required condition passes, RWAPACT authorizes execution. The trade can proceed to the execution layer, and KAR records the approval context.

If one condition fails, RWAPACT rejects the trade. It returns a reason code, and KAR records the rejection context. The execution layer receives no authorization.

```
Agent Intent
  -> Risk Check
  -> Session Check
  -> Policy Check
  -> Gas Check
  -> Attestation
  -> Execution if approved
```

### Why This Matters

RWAPACT does not replace the trading venue. It inserts a decision layer before execution.

An autonomous agent cannot treat every valid transaction request as an automatically valid trade. The Pact requires the request to satisfy risk, session, policy, and gas conditions first.

***


---

# 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/tokenized-stock-trading.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.