> 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/system-architecture/architecture-overview.md).

# Architecture Overview

## Architecture Overview

RWAPACT is structured as a middleware system. It receives a trade intent from an autonomous agent, evaluates that intent through the Pact Gate and its supporting components, and passes an authorized trade to the execution layer.

The architecture separates three responsibilities from the outset:

```
Agent
  |
  v
RWAPACT
  |
  v
Execution Layer
```

The agent produces an action request. RWAPACT evaluates and authorizes that request. The execution layer carries out the authorized trade. The system structure keeps the decision boundary distinct from both the agent and the execution path.

### System component map

Within RWAPACT, KRO, KSO, KPV, Pact Gate, KGR, and KAR form the core architecture. The components have separate roles, but they operate along one decision path.

| Component                 | Architectural role                          |
| ------------------------- | ------------------------------------------- |
| KRO, Risk Oracle          | Provides RWA risk evaluation                |
| KSO, Session Oracle       | Validates session and delegated authority   |
| KPV, Policy Vault         | Enforces policy constraints                 |
| Pact Gate                 | Coordinates the decision process            |
| KGR, Gas Router           | Evaluates gas and execution-path conditions |
| KAR, Attestation Registry | Records the decision and relevant context   |

KRO, KSO, and KPV provide the core decision inputs. Pact Gate connects and coordinates those components before authorization. KGR evaluates the gas and execution conditions that also form part of the decision. KAR records the resulting approval or rejection.

The following diagram shows the intended relationship between the components:

```
                         Agent
                           |
                           v
┌──────────────────────────────────────────────────┐
│                     RWAPACT                      │
│                                                  │
│       KRO             KSO             KPV        │
│        \               |               /          │
│         \              |              /           │
│                 Pact Gate                         │
│                     |                            │
│                    KGR                           │
│                     |                            │
│                    KAR                           │
└─────────────────────┼────────────────────────────┘
                      |
                      v
              Execution Layer
          DEX / MCP / Robinhood API
```

The diagram presents the architectural relationship, not a complete contract or service topology. It shows that execution sits beyond the core RWAPACT decision logic.

### Pact Gate as the orchestration point

Pact Gate is the system's orchestration point. It connects the decision components and coordinates their flow before execution authorization.

Pact Gate does not introduce a separate risk model. Risk intelligence comes from KRO. Session authority comes from KSO. Policy constraints come from KPV. Gas and execution-path conditions come from KGR. Pact Gate coordinates these inputs into the path that determines whether execution may proceed.

This role makes the decision process explicit at the architectural level. The components retain their defined responsibilities while the gate provides a single point for coordinating the authorization flow.

### Execution boundary

The execution layer sits outside RWAPACT's core decision logic. It performs the actual transaction only after the Pact has authorized the proposed trade.

| Layer           | Responsibility                |
| --------------- | ----------------------------- |
| Agent           | Produces trade intent         |
| RWAPACT         | Evaluates and authorizes      |
| Execution layer | Executes the authorized trade |

The execution layer can represent DEX execution, MCP execution, or Robinhood API execution. These are execution-layer examples in the protocol design. They do not imply that every path is deployed or available through a current integration.

RWAPACT therefore does not require the execution layer to become the risk engine. It provides a dedicated authorization boundary before execution while leaving transaction execution to the appropriate downstream path.

### Architectural data flow

At a high level, a proposed trade follows this path:

```
Trade Intent
  -> Pact Gate
  -> Risk / Session / Policy Evaluation
  -> Gas Evaluation
  -> Attestation
  -> Execution Authorization
  -> Execution Layer
```

The precise implementation path can vary with the execution integration. The decision boundary remains consistent: relevant conditions are evaluated before the trade receives authorization to proceed.

KAR records the outcome and relevant context. Its attestation function does not replace execution. It preserves the decision associated with an authorization or rejection.

### On-chain and off-chain boundaries

RWAPACT includes protocol-level smart contract components and supporting off-chain infrastructure. The whitepaper identifies Solidity `^0.8.24` for smart contracts, Chainlink for oracle infrastructure, ERC-8004 for identity, and ERC-8273-compatible attestation.

It also identifies viem for RPC interactions, Next.js API routes for backend services, and Prisma with PostgreSQL for database infrastructure. The off-chain backend responsibilities include risk computation, session state, risk cache, and event logging.

These technologies describe components across the broader system architecture. They do not establish that every calculation or subsystem is exclusively on-chain or exclusively off-chain. The decision boundary remains the key architectural concern. [On-Chain and Off-Chain Components](/whitepaper/system-architecture/on-chain-and-off-chain-components.md) examines these boundaries in greater detail.

### A separated trade architecture

RWAPACT separates intent, decision, authorization, execution, and attestation. This arrangement places the Pact Gate and its supporting components between an autonomous agent and the system that executes the trade.

The next page, [Agent to Pact Gate to Execution](/whitepaper/system-architecture/agent-to-pact-gate-to-execution.md), follows a trade intent through that structure from request to execution outcome.


---

# 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/system-architecture/architecture-overview.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.