Skip to main content
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. 
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. 
{
  "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. 
{
  "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:
SignalWeightSource
Registry capability probes35%Live synthetic transactions
Ledger attestation records30%On-chain auditor signatures
Operational metrics20%Uptime, error rates, latency
Cross-registry reputation15%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

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.
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.
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.