> 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/on-chain-and-off-chain-components.md).

# On-Chain and Off-Chain Components

How RWAPACT separates smart-contract enforcement from supporting off-chain computation, state management, and infrastructure.

## On-Chain and Off-Chain Components

RWAPACT combines on-chain protocol enforcement with off-chain infrastructure where computation or persistent application state is required. The distinction is practical. Each responsibility lives where it can support the decision flow without moving the authorization boundary away from the protocol.

```
Agent / Application
        |
        v
Off-Chain Infrastructure, where required
        |
        v
On-Chain RWAPACT Contracts
        |
        v
Execution Layer
```

The boundary depends on the responsibility being performed. Supporting systems can supply context and computation. RWAPACT contracts retain the protocol-level checks that govern authorization before execution.

### On-chain components

The core protocol contracts use Solidity `^0.8.24`. They comprise the five component contracts and Pact Gate:

* KRO, Risk Oracle
* KSO, Session Oracle
* KPV, Policy Vault
* KGR, Gas Router
* KAR, Attestation Registry
* Pact Gate

These components live at the protocol layer because they define the enforceable decision path. They validate delegated authority and sessions, apply policy constraints, coordinate the required decision checks, assess gas and execution conditions, and record attestations.

The five checks are smart contract calls. Pact Gate coordinates their role in the authorization flow before a trade can reach an execution environment. This does not require every supporting input or calculation to originate on-chain. It requires authorization to remain connected to the contract logic that applies the Pact.

### Off-chain components

The supporting backend uses Next.js API routes for off-chain risk computation. Prisma and PostgreSQL support session state, a risk cache, and an event log.

Some responsibilities need off-chain infrastructure because they involve persistent application state, caching, event processing, or context such as market calendar data. Supporting services can also prepare inputs used during risk evaluation.

These systems do not independently authorize trades. The RWAPACT decision layer remains the authorization boundary. Off-chain infrastructure supports the evaluation path, while the protocol applies its required checks before execution.

### External data and protocol standards

The architecture uses external standards and integrations for defined responsibilities. They provide context or connectivity around the decision layer.

| Component        | Technology          | Architectural role                    |
| ---------------- | ------------------- | ------------------------------------- |
| Smart Contracts  | Solidity `^0.8.24`  | Core protocol contracts and Pact Gate |
| Oracle           | Chainlink           | RWA stock token price feeds           |
| Identity         | ERC-8004            | Agent identity and reputation         |
| Attestation      | ERC-8273 compatible | Attestation interoperability          |
| Payment          | EIP-3009 / x402     | Gasless payment authorization         |
| Pool Integration | Uniswap v4          | RWA liquidity access through hooks    |
| RPC              | viem                | Blockchain interaction                |
| Backend          | Next.js API routes  | Off-chain risk computation            |
| Database         | Prisma + PostgreSQL | Session state, risk cache, event log  |

The table describes how the pieces relate to RWAPACT's architecture. It does not make each technology a separate decision system. The Pact remains the point where required authorization conditions are evaluated.

### The on-chain and off-chain boundary

Off-chain infrastructure can provide data, computation, caching, and application state. Protocol-level authorization still needs an enforceable boundary before execution.

RWAPACT can use off-chain computation where appropriate. The resulting decision must still pass through smart-contract logic that evaluates the required authorization conditions. This keeps computation and state management flexible without treating a supporting service as the final trade authority.

### Example: RWA risk evaluation

KRO may require information such as a Chainlink feed timestamp, market price versus oracle price, liquidity information, market-hour information, token freeze status, concentration, and volatility.

Supporting infrastructure may supply data or calculations needed for that evaluation. The resulting risk context still enters the RWAPACT authorization flow. KRO's role is part of the required decision path, not a separate advisory step.

### Architectural takeaway

RWAPACT is neither simply on-chain nor off-chain. Smart contracts provide protocol-level enforcement. Off-chain infrastructure supports computation and state. External standards and data sources provide required context. Execution remains a separate layer.

[Trade Lifecycle](/whitepaper/system-architecture/trade-lifecycle.md) follows a trade as it moves through these components.


---

# 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/on-chain-and-off-chain-components.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.
