Clearcompass
Get started
Architecture overview

A public, witness-cosigned, append-only log — for any domain.

Attesta is structurally similar to Certificate Transparency, generalized so that any industry — court records, real estate deeds, supply chains, or agent authority — can build on it without reinventing the underlying cryptographic protocol.

The system’s resilience relies on four distinct roles, powered by a modular stack of cryptographic subsystems.

SUBMITTERS
Senders

Sign records before they leave

EXCHANGE · NETWORK
The logbook + operator

Append-only log, pinned by genesis fingerprint

PUBLIC
Open publication

Snapshots anyone can pull

WITNESS PANEL
Live K-of-N consensus

Independent co-signers block rollbacks in real time. They verify the log only grew — never that it shrank.

AUDITORS
Post-hoc verification

Independent watchdogs pull every snapshot, re-run the math, and emit fraud proofs on equivocation.

core protocol actors & tooling → data flow
§1 · The trust model

Four roles. No single point of failure.

The cryptographic guarantees come from how the roles constrain each other — not from trusting any one of them.

01 · The logbook

Network

The fundamental, tamper-proof logbook. Every Network is born with a permanent cryptographic fingerprint derived from its founding charter: who runs it, its name, its starting state, and its initial panel of Witnesses.

Familiar analogy

A specific Git repository with a permanently pinned root commit.

Architectural value

The fingerprint is woven into every subsequent record. An operator cannot misbehave, delete the log, and quietly restart under the same identity. A record from one Network cannot be forged or replayed onto another.

02 · The operator

Exchange

The legal and operational entity running the Network. The Exchange maintains the infrastructure, manages the API surface, and authenticates users.

Familiar analogy

The organization hosting the system — e.g. a county recorder's office.

Architectural value

The Exchange owns the infrastructure, but cannot rewrite history. Cryptography heavily restricts their power: they can only append new records, and they can only do so while everyone is watching.

03 · The live signer

Witness

An independent co-signer. Before the Exchange can publish a new batch of records, a quorum (K-of-N) of Witnesses must co-sign the update.

Familiar analogy

Independent decentralized notaries.

Architectural value

Witnesses are blind notaries — they don't need to read the records. They simply verify that the log is growing and never shrinking, which prevents rollbacks. Because their job is mathematically lightweight, it's easy to recruit highly decentralized, independent parties.

04 · The post-hoc verifier

Auditor

An independent watchdog. Auditors continuously ingest the public log, re-verify all signatures locally, and check for equivocation — when an Exchange tries to secretly maintain two different versions of history.

Familiar analogy

A continuous monitoring service — like crt.sh for SSL certificates.

Architectural value

If an Auditor catches an Exchange lying, they generate a cryptographic proof of the fraud. That triggers an automated slashing event which strips the Exchange of its trust weight across the broader ecosystem. Getting caught is economically and operationally terminal.

§2 · Trust boundaries · layered resilience

Layered resilience. Each role is the safety net for the next.

The system is designed under the assumption that any single actor might be compromised. The cryptography defines the limits.

Role Can do Cannot do
Exchange Can
Append entries · authorize users · host the data. 		Cannot
Rewrite history · fork the log without detection · publish un-witnessed updates.
Witness Can
Block rollbacks in real time by refusing to sign. 		Cannot
View payload contents · inject their own entries · independently catch historical forks.
Auditor Can
Detect any equivocation · trigger slashing · persist evidence. 		Cannot
Prevent a bad update from being created — they catch it after the fact.
End user Can
Cryptographically prove a record's authenticity — completely offline, forever. 		Cannot
Requires only the genesis keys and the proof file — no servers, no accounts.
Summary

The Witness panel makes live cheating incredibly difficult. Open publication makes hiding a cheat impossible. The Auditor network makes getting caught fatal.

§3 · Core subsystems

Under the hood.

To achieve offline verifiability and machine-native trust, Attesta is broken down into highly specialized processing packages. Each owns one cryptographic responsibility — together they form the modular stack the four roles operate.

Inputs
SIGNER
Human key
ECDSA · Ed25519
SIGNER
Smart contract
EIP-1271
SIGNER
DID / ZK
Iden3 · did:eth
SIGNER
AI agent
delegated key
IDENTITY · SIGNATURES
did, crypto
named actors · verifiable sigs
AUTHORIZATION
authz
ephemeral WriteAuthorization
THE ENGINE sequencer · tessera
RFC 6962 · C2SP tlog-tiles
root h1 h2 a b c d e #1 #2 #3 #4 #5 #6 #7 Sparse Merkle Tree
EMIT tile 0x8b3a… static · cacheable GCS · S3 · R2 CDN edge Gossip feed
Tessera inserts each record into the embedded Sparse Merkle Tree, generates an RFC 6962-compliant inclusion proof, and packages the new tree state into static, highly cacheable tiles. The sequencer is blind to domain logic — it only orders & hashes.
CONSENSUS · K-of-N
quorum
witness fanout · threshold sigs · BLS12-381
PUBLISHED
gossip
network states · fanout
CLIENTS
verifier
offline · delegation trees
AUDITORS
auditor
re-derive · fraud proofs
did · crypto

Identity & signatures

Every actor is cryptographically named. Natively supports smart-contract wallets and AI agents as legal signers — not just human keys.

Ed25519 ECDSA secp256k1 EIP-1271 EIP-191 / -712 Iden3 ZK
authz

Authorization

Payment and authorization are decoupled. Every entry requires a detached, ephemeral WriteAuthorization proving an on-log authority approved it.

WriteAuthorization scoped + expiring
sequencer · tessera

The engine

The core database is blind to domain logic. The sequencer assigns gapless positions; Tessera inserts records into a Sparse Merkle Tree, generates inclusion proofs, and emits static tiles.

Sparse Merkle Tree RFC 6962 C2SP tlog-tiles
quorum

Consensus

Before Tessera publishes a new tree head, the update is fanned out. The quorum package collects signatures and enforces the K-of-N threshold.

K-of-N BLS12-381 aggregate
gossip · verifier

Watchdogs

The gossip feed broadcasts new network states. The verifier lets any offline user mathematically trace authority through delegation trees, proving an event happened at an exact moment in time.

fraud-proof emit delegation trace offline
tiles · cache

Static publication

Every checkpoint becomes a content-addressed tile written to public, read-only object storage (GCS / S3 / R2). Verification is a CDN cache hit — not an API call.

GCS · S3 · R2 edge-cacheable
§4 · System interplay

The data lifecycle.

Alice (a court clerk) submits a ruling. Bob (a lawyer) needs to verify it five years later — entirely offline, after the original Exchange no longer exists.

1
Submitter → Exchange

Submission & authentication

Alice submits the ruling. The Exchange authenticates her digital signature and verifies she has the authorization to write to this specific log.

2
Exchange

Sequencing

The system accepts the record, assigns it a permanent position, inserts it into the cryptographic tree, and issues Alice a receipt promising publication.

3
Exchange ⇄ Witnesses

Cosigning · live consensus

The Exchange packages the new log state and sends it to the decentralized Witness panel. Once a quorum (K-of-N) confirms the log hasn't been rolled back, they apply their signatures.

4
Exchange → Public

Publication

The updated, co-signed log is published openly. Anyone can pull it down.

5
Auditors

Continuous audit

Independent Auditors instantly pull this new update, re-verifying the math to ensure the Exchange hasn't created a hidden fork of the log.

6
End user · offline

Future offline verification

Five years later, the original Exchange may no longer exist. Bob still has a digital proof file of the ruling. Because the trust relies on math — not infrastructure — Bob runs a local verifier and cryptographically proves the record was included and properly witnessed at the time.

Keep reading

Go deeper.

Walkthrough
How it works →
Six visual steps from signing to verification.
Source
Open source →
The SDK, ledger, and tooling. Run it yourself.
Questions
FAQ →
Common questions about Attesta and Clearcompass.