Understanding Blockchain Attestation
How cryptographic anchoring works — explained simply
The Principle in 30 Seconds
Every governance decision is cryptographically hashed (SHA-256). For projects with attestation enabled, pending hashes are combined into a Merkle tree every 30 seconds and the root hash of this tree is anchored on the Flare blockchain.
Result: An auditor can mathematically prove that a specific decision took place — without platform access and without the possibility of retroactive manipulation.
Why Blockchain and Not Just a Database?
Database entries can be changed by an administrator. A SHA-256 hash on a public blockchain cannot. This is the key difference from all competitors that offer only database-based logs.
The Three-Level Model
| Level | Description | When |
|---|---|---|
| Always on-chain | Trace is always captured by the attestation rules; the scope setting cannot exclude it. | Blocked decisions, agent lifecycle events, approvals |
| Automatic | System decides contextually. Project owner can override. | Default for regular traces |
| Local only | Database only. No blockchain entry. | Development/test environments |
Cost
Through batching (hundreds of traces in a single blockchain transaction), the per-transaction cost is minimal.
Flare Blockchain
The platform uses the Flare Network blockchain (Coston2 testnet; managed Mainnet is Enterprise-only and not yet in regular operation). Flare was chosen for low transaction costs, EVM compatibility, and the Flare Data Connector (FDC) for future cross-chain proofs.