> 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/the-five-layer-pact/kar-attestation-registry.md).

# KAR, Attestation Registry

## KAR, Attestation Registry

A decision is difficult to inspect later without a durable record of the requested trade and its outcome. KAR preserves the decision context produced by the Five-Layer Pact.

KAR is the record-keeping and attestation layer. It does not determine whether a trade is safe. It records what the Pact decided and the context associated with that decision.

That context includes:

* The requested trade, agent, and active session.
* The risk score, policy version, and selected gas route.
* The approval or rejection outcome and execution result.

### Attestation record

| Field             | Meaning                                                 |
| ----------------- | ------------------------------------------------------- |
| `attestationId`   | Identifies the attestation record.                      |
| `agentId`         | Identifies the requesting agent.                        |
| `sessionId`       | Identifies the session associated with the request.     |
| `asset`           | Identifies the requested asset.                         |
| `amount`          | Records the requested trade amount.                     |
| `riskScore`       | Records the KRO risk assessment.                        |
| `policyVersion`   | Records the active policy version.                      |
| `gasRouteHash`    | References the selected gas route.                      |
| `approved`        | Records whether the Pact approved the trade.            |
| `rejectReason`    | Records the rejection reason when applicable.           |
| `timestamp`       | Records the decision time.                              |
| `executionTxHash` | Records the execution transaction hash after execution. |

`executionTxHash` is populated after execution. It is not present for a rejected trade that never executes.

### Approved decision

```
Trade
  -> Pact Checks Pass
  -> Authorization
  -> KAR Attestation
  -> Execution
  -> executionTxHash associated with attestation
```

For an approved decision, KAR preserves the decision context and later links it to the execution transaction reference.

### Rejected decision

```
Trade
  -> Pact Check Fails
  -> Rejection
  -> Reason Code
  -> KAR Attestation
  -> No Execution
```

Rejected trades are also attested. KAR is not limited to successful transactions. A rejected decision remains part of the protocol's recorded history.

### ERC-8273 compatibility

KAR implements the ERC-8273 interface for interoperability with other attestation-based systems. It adds an RWA-specific attestation schema defined by the specification.

This statement is limited to the specified compatibility. It does not claim full compatibility with every external attestation system.

### One decision record

KAR connects context from the Pact's operational layers:

```
KRO --|
KSO --|
KPV --|-> KAR Attestation
KGR --|
Trade -|

KAR
  |
  v
Approved or Rejected
  |
  v
Execution Tx Hash if executed
```

KRO contributes the risk score. KSO contributes session ID and agent context. KPV contributes the policy version. KGR contributes the gas route hash. Execution contributes the transaction hash after execution.

Together, these values form a single record associated with the decision.

### Protocol-level auditability

The attestation architecture supports protocol-level auditability and traceability by:

* Preserving decision context.
* Tracing the authorization outcome.
* Connecting a decision to its execution transaction.
* Providing a durable record for later inspection.

KAR does not itself create legal compliance or automatically resolve disputes. Its responsibility is to preserve the protocol decision record.

### Example: risk-blocked trade

An agent requests an RWA trade. KRO returns a risk score of `85`, and KPV determines that the configured risk threshold is exceeded.

The Pact rejects the trade. KAR records the agent ID, session ID, asset, amount, risk score, policy version, rejection reason, and timestamp. No execution transaction hash is present because the trade never executed.

For an approved trade, the same decision context is attested. `executionTxHash` is populated after execution.

### Why KAR closes the Pact

The first four layers answer operational questions:

| Layer | Responsibility                             |
| ----- | ------------------------------------------ |
| KRO   | RWA-specific risk assessment               |
| KSO   | Session and delegated authority validation |
| KPV   | Configurable policy enforcement            |
| KGR   | Gas and execution-path optimization        |

KAR preserves the resulting decision. This is why KAR closes the Five-Layer Pact rather than acting as another approval layer.

| Layer | Primary Question                                    |
| ----- | --------------------------------------------------- |
| KRO   | Is the trade within acceptable RWA risk conditions? |
| KSO   | Is the agent authorized within the current session? |
| KPV   | Does the trade comply with policy?                  |
| KGR   | Are gas and execution conditions acceptable?        |
| KAR   | What decision was made and under what context?      |

The reader now understands each component individually. [Pact Execution](/whitepaper/pact-execution/trade-intent.md) explains how these components operate together during actual trade execution.

***


---

# 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/the-five-layer-pact/kar-attestation-registry.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.