> 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/roadmap-and-vision/the-middleware-position.md).

# The Middleware Position

## The Middleware Position

RWAPACT is not the executor. It is the decision layer that determines whether an autonomous RWA trade should be allowed to reach execution.

Existing trading components can provide DEX liquidity and routing, wallet custody and signing, agent intent parsing, and spend limits or policy controls. These components are primarily optimized around execution. RWAPACT adds a dedicated risk and decision layer before that execution occurs.

```
Agent
  |
  v
RWAPACT Pact Gate
  |
  v
Existing Execution Layer
```

The Pact Gate evaluates the requested trade. The execution layer acts only after RWAPACT authorizes the request.

### The five-layer Pact

The middleware position is defined by five separate responsibilities:

| Layer | Responsibility                             |
| ----- | ------------------------------------------ |
| KRO   | RWA-specific risk assessment               |
| KSO   | Session and delegated authority validation |
| KPV   | Policy enforcement                         |
| KGR   | Gas optimization                           |
| KAR   | Attested decision record                   |

KRO evaluates current RWA risk conditions. KSO confirms that the agent can act within an active session. KPV tests the trade against configured policy. KGR evaluates gas and route conditions. KAR preserves the resulting approval or rejection context.

These layers form one decision boundary. None replaces the execution infrastructure that follows.

### Execution-layer agnosticism

RWAPACT is designed to wrap existing execution paths rather than become another execution venue. The execution layer can differ by integration.

| Integration   | Middleware role                                                                     |
| ------------- | ----------------------------------------------------------------------------------- |
| Uniswap v4    | A hook runs the Pact before allowing the swap.                                      |
| MCP           | Middleware intercepts agent tool calls before forwarding them to the execution MCP. |
| Robinhood API | A proxy runs the Pact before forwarding the trade request.                          |

These examples describe how the same decision model can sit ahead of distinct execution paths. RWAPACT does not replace Uniswap v4, MCP execution servers, or the Robinhood API.

### Why Middleware?

Replacing the execution layer would require rebuilding liquidity, custody, routing, and existing agent integrations. The middleware approach adds risk controls without requiring the entire trading stack to be replaced.

It also preserves a clear separation of responsibilities. Agents generate intent. Execution systems perform authorized transactions. RWAPACT evaluates whether the proposed action should proceed.

> RWAPACT does not execute trades. RWAPACT decides whether a trade should execute.


---

# 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/roadmap-and-vision/the-middleware-position.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.