> ## Documentation Index
> Fetch the complete documentation index at: https://mwillaimission.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Trust Ledger: Immutable On-Chain Trust Attestations

> See how AgentLedger anchors trust attestations on-chain so any agent can independently verify service trust history without relying on a single authority.

The AgentLedger Trust Ledger is the security spine of the platform. It addresses the fundamental problem that every centralized trust registry creates: if you trust one entity to maintain the trust infrastructure, that entity becomes both a single point of failure and a single point of corruption. The Trust Ledger solves this by storing attestation records on a distributed ledger — making them immutable, independently verifiable, and resistant to manipulation by any single actor, including AgentLedger itself.

## Core design: the ledger as notary

The Trust Ledger splits responsibility between off-chain and on-chain infrastructure along a clear boundary: performance on one side, trust on the other.

```text theme={null}
OFF-CHAIN (performance)        ON-CHAIN (trust)
┌─────────────────────┐       ┌──────────────────────┐
│ Manifest index      │       │ Attestation events   │
│ Query API           │  ←→   │ Revocation events    │
│ Ranking engine      │       │ Version history      │
│ Search interface    │       │ Cryptographic proofs │
└─────────────────────┘       └──────────────────────┘
```

The off-chain layer handles the manifest index, query API, ranking engine, and search interface — all the operations that require low latency and high throughput. The on-chain layer holds the cryptographic proof layer that makes trust claims independently auditable. You can query the off-chain layer for speed, then verify against the on-chain layer for certainty.

## Three on-chain event types

Every trust-relevant action produces an on-chain event. These events are the permanent, tamper-proof record that any party can inspect.

### Attestation events

Attestation events are auditor-signed records confirming that a service passed a capability probe, security review, or compliance certification at a specific point in time.

```json theme={null}
{
  "event_type": "attestation",
  "service_id": "uuid-of-service",
  "auditor_id": "uuid-of-auditor",
  "auditor_signature": "...",
  "capability_tags_verified": ["travel.air.book", "travel.air.cancel"],
  "timestamp": "2026-04-10T00:00:00Z",
  "expiry": "2027-04-10T00:00:00Z"
}
```

### Revocation events

Revocation events record trust withdrawals, including the reason code and the auditor's identity. These records are immutable — they cannot be deleted even by the service that was revoked.

```json theme={null}
{
  "event_type": "revocation",
  "service_id": "uuid-of-service",
  "reason_code": "capability_misrepresentation",
  "auditor_id": "uuid-of-auditor",
  "timestamp": "2026-04-10T00:00:00Z"
}
```

### Version events

Version events are signed records of manifest changes. They create an immutable history of what a service claimed at any given point in time — enabling liability attribution because a service cannot retroactively alter what it declared.

## Trust score composite

AgentLedger computes a dynamic trust score for each service by combining four weighted signals:

| Signal                     | Weight | Source                       |
| -------------------------- | ------ | ---------------------------- |
| Registry capability probes | 35%    | Live synthetic transactions  |
| Ledger attestation records | 30%    | On-chain auditor signatures  |
| Operational metrics        | 20%    | Uptime, error rates, latency |
| Cross-registry reputation  | 15%    | Federated blocklist signals  |

Scores are dynamic and update continuously as new evidence is collected. A service that passes a capability probe today and gets revoked tomorrow will see its score reflect the revocation immediately.

## Why blockchain and not a centralized database

<Warning>
  A centralized trust registry creates a single point of failure and a single point of corruption. If AgentLedger's database is compromised, every trust score in the ecosystem is compromised simultaneously.
</Warning>

On-chain attestations solve this because:

* Any agent can independently verify a service's trust history **without querying AgentLedger directly**
* Attestation records cannot be deleted or modified retroactively by any party
* The audit trail is publicly inspectable — trust is not a black box
* Cross-registry reputation federation happens natively through shared ledger access

## Chain selection rationale

The Trust Ledger does not use Ethereum mainnet — the write throughput is too low and gas costs are too high for high-frequency attestation writes. The target architecture is a **purpose-built L2 or permissioned chain** optimized for write throughput and low gas costs, similar to the Hyperledger Fabric model used in enterprise supply chain trust systems.

Final chain selection is an open design question. See [Roadmap](/roadmap).

<Info>
  The chain selection decision does not affect the on-chain event schema or the off-chain query API. Your integration with the Trust Ledger remains stable regardless of which chain the attestation layer runs on.
</Info>