> 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/protocol-economics/revenue-model.md).

# Revenue Model

Explains how RWAPACT is designed to generate protocol revenue from validated RWA trading, gas optimization, enterprise risk services, and attestation queries.

## Revenue Model

RWAPACT monetizes the decision and infrastructure layer around autonomous RWA trading. It does not act as the execution venue itself.

The current protocol economics define four revenue streams. Each stream relates to a protocol function that supports trading validation, gas-aware execution, risk intelligence, or decision lookup.

| Revenue stream      | Source                                      | Current model                    |
| ------------------- | ------------------------------------------- | -------------------------------- |
| Protocol fee        | Validated RWA trade volume                  | `0.3%` of validated trade volume |
| Gas savings share   | Savings generated through KGR optimization  | `10%` of gas savings             |
| Enterprise Risk API | Third-party access to risk scoring services | Subscription-based access        |
| Attestation query   | Lookups of stored decision attestations     | Per-query fee                    |

These streams are the protocol's current economic design. They do not represent realized revenue, revenue projections, or financial guarantees.

### Validated trade volume

Validated trade volume refers to trades that pass through RWAPACT's Pact validation process. The protocol evaluates the trade intent before it can receive authorization for execution.

This differs from arbitrary activity outside the middleware. A trade that does not use the Pact is not validated trade volume within this model.

The Pact combines risk evaluation from KRO, session validation from KSO, policy enforcement from KPV, and gas-route evaluation from KGR. KAR records the resulting decision context.

### Protocol fees

The protocol fee is associated with validated trading activity. It connects protocol economics to use of the decision layer before execution.

The current model applies a `0.3%` fee to validated trade volume. The model does not state that every attempted or rejected request necessarily generates that fee.

### Gas savings share

KGR evaluates gas conditions and available execution paths. When KGR produces measurable savings, the model assigns `10%` of those savings to the protocol.

The savings share depends on the difference between a baseline gas cost and an optimized gas cost. It does not guarantee that every route will produce savings.

### Enterprise Risk API

The Enterprise Risk API provides a subscription-based model for third parties that need RWAPACT risk scoring capabilities. Those applications may need risk intelligence without using the complete trading middleware.

This model extends access to the KRO risk assessment capability. It does not change KRO's role inside the Pact.

### Attestation queries

KAR preserves decision attestations for approved and rejected trade requests. Applications that query those stored records can use the attestation-query revenue stream.

The current model defines this as a per-query fee. It does not define a fee amount or usage volume here.

### A diversified protocol model

RWAPACT operates across several stages of autonomous RWA trading:

* Decision validation
* Execution optimization
* Risk data access
* Decision verification and lookup

The economics therefore do not depend on one type of protocol usage. Each stream maps to a separate function within the wider system.

### Revenue Follows Protocol Utility

Each revenue stream is tied to a concrete protocol function. The model links fees to validated trade activity, measurable optimization, risk-service access, or attestation lookup.

***


---

# 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/protocol-economics/revenue-model.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.