> 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/introduction/the-rwa-risk-gap.md).

# The RWA Risk Gap

## The RWA Risk Gap

The previous page separated transaction execution from the decision to allow a trade. That distinction becomes more important for tokenized Real-World Assets (RWAs).

An RWA represents an asset with a trading context that can extend beyond the blockchain transaction. That context may include market data, trading schedules, liquidity conditions, exposure limits, or applicable restrictions. A transaction can be valid on-chain while those conditions make execution inappropriate at that moment.

This does not mean every RWA has the same risk profile. Asset structures, markets, and governing rules vary. It means that tokenized assets can introduce dependencies and constraints that the transaction itself does not fully express.

RWA execution therefore requires awareness of the asset's current risk context, not just transaction validity.

{% hint style="info" %}
**Transaction validity is not the same as trade suitability.**

A valid transaction tells the blockchain that an action can execute. RWA-aware decision logic asks whether the action should execute under current conditions.
{% endhint %}

### Beyond the transaction

Blockchain infrastructure can verify important facts. It can verify a signature, apply contract rules, and process a correctly formed transaction. These checks establish that the requested state change is executable at the protocol level.

They do not necessarily evaluate the condition of the asset being traded. A tokenized stock may have a valid transfer path while its reference price is outdated. An asset can remain technically tradable while liquidity cannot support the proposed size. A valid call can also occur when an external restriction should prevent the trade.

The gap is not a failure of blockchain validity checks. Those checks answer a different question. They determine whether a transaction meets the rules required for execution. Asset-risk evaluation determines whether the proposed trade remains acceptable within its current market, policy, and operational context.

For RWAs, the two questions often need to be considered together:

* Can this transaction execute?
* Should this trade execute under the current conditions?

The first question alone cannot represent every relevant decision variable.

### The RWA risk surface

The risk surface for an RWA trade can include data quality, market conditions, operating constraints, and portfolio exposure. These inputs matter because an autonomous trade acts on the conditions available when it moves toward execution.

| Risk dimension    | Why it matters to autonomous execution                                    |
| ----------------- | ------------------------------------------------------------------------- |
| Oracle staleness  | A decision may rely on market information that is no longer current.      |
| Price deviation   | The executable price may differ materially from reference conditions.     |
| Liquidity depth   | Available liquidity may not support the intended trade size.              |
| Slippage          | The expected price can deteriorate as the order uses available liquidity. |
| Market hours      | The asset may operate within trading or settlement windows.               |
| Compliance freeze | Restrictions may require execution to be blocked.                         |
| Concentration     | A trade may raise exposure to one asset beyond an acceptable threshold.   |
| Volatility        | Fast market movement can change risk between intent and execution.        |

#### Oracle staleness and price deviation

An agent may form an intent using a reference price. That reference only supports a sound decision when it remains sufficiently current for the intended trade. If the underlying information is stale, the agent may act on conditions that no longer reflect the market.

Fresh information alone does not guarantee an executable price matches the reference. A material deviation can arise between the expected market condition and the price available for the trade. The decision context must account for both the age of the information and its relationship to execution conditions.

#### Liquidity depth and slippage

Tradability is not binary. An asset may have a valid venue and an available route, yet the market may lack enough depth for a particular order size. The trade can still execute, but it may do so at a price that no longer fits the intended conditions.

Slippage describes that deterioration as an order interacts with available liquidity. For an autonomous agent, intended size and expected execution conditions must remain connected. Otherwise, an order that appears reasonable when proposed may produce an unsuitable outcome when filled.

#### Market hours and compliance restrictions

Tokenized assets can be linked to markets or processes that follow defined schedules. These schedules may differ from always-on crypto markets. A blockchain remains available continuously, but the relevant asset context may not.

Restrictions can also change whether a trade should proceed. A compliance freeze may apply to an asset or market and require execution to stop. A transaction does not become malformed because a restriction exists. The restriction changes the decision about whether the trade should be authorized.

#### Concentration and volatility

Risk also depends on the proposed trade's effect on exposure. A purchase may be valid and liquid enough to execute while increasing concentration in a single asset beyond an accepted boundary. This depends on the trade in context, not only on the asset's availability.

Volatility introduces a timing problem. Prices and market conditions can change between an agent forming an intent and submitting the resulting transaction. The longer or more dynamic that interval becomes, the more important it is to evaluate the conditions relevant to execution.

These dimensions are not promises of perfect detection. They identify the context that can matter before an autonomous RWA trade is allowed to proceed.

### Why autonomy changes the check

A human trader can inspect conditions before approving a trade. That review may include price movement, market status, available liquidity, or applicable restrictions. The review is part of the decision process, even when it happens quickly.

An autonomous agent may act from its strategy, data, or instructions without a person reviewing each action. It can create an intent when conditions appear to meet its goals. By the time the trade reaches execution, those conditions may have changed or may need to be checked against explicit limits.

This does not make autonomous agents inherently unsafe. It also does not assume that human traders always decide better. Autonomous execution changes where the decision checks need to exist. Conditions that a human might inspect during approval need an explicit, enforceable place in the execution path.

The issue is not whether an agent can reason about risk. The issue is whether risk evaluation is required before execution, rather than left as an assumption in the agent's earlier reasoning.

### Asset risk and transaction risk

Transaction risk and asset risk are related but distinct. Transaction validity concerns the action submitted to the blockchain. Asset risk concerns whether trading the represented asset makes sense under the conditions surrounding that action.

A transaction may have:

* A valid signature from an authorized key.
* A correctly formed contract call.
* Satisfied the blockchain's basic execution rules.

The underlying RWA trade may still involve stale pricing, insufficient liquidity, unfavorable slippage, an active restriction, or excessive concentration. None of these conditions necessarily invalidate the transaction at the protocol level. They can still make the trade unsuitable for the authorization under which the agent operates.

This distinction avoids treating the execution stack as incomplete or unsafe. Execution infrastructure remains responsible for routing, signing, and settlement. RWA trading introduces additional decision variables that an execution-only stack may not evaluate.

### Context before authorization

The practical requirement is straightforward. Before an autonomous RWA trade is authorized, the relevant asset context needs to be available to the decision process.

That context does not eliminate market risk. It does not guarantee every condition is observable or predictable. It makes the conditions that matter explicit, so they can inform whether a proposed action remains within its intended constraints.

RWA trading requires more than a path to execution. It requires a mechanism that can evaluate relevant context before execution is authorized. The next page, [Why a Decision Layer Matters](/whitepaper/introduction/why-a-decision-layer-matters.md), develops that requirement.


---

# 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/introduction/the-rwa-risk-gap.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.
