docs/verifiable-not-trusted.mdpinned to impactium@637886d

Verifiable, not trusted

Impactium asks you to trust it as little as possible. Almost every claim the network makes about itself can be checked cryptographically — against the chain's own committed state, with the same code the chain uses, without trusting the team, the servers, or even a full node. This page is the map of what you can verify and how.

The principle

A record is worth what it can be proven to be. So the system is built so that the parts that carry value are exactly the parts you can independently verify:

  • Impact records are permanent and provable against a committed state root.
  • The read layer (Karma) is a disposable projection — never a source of truth.
  • Distributed code (Chain Resources) is content-addressed and hash-verified.
  • Transactions sign to a byte-exact, cross-checked wire format.

None of these are policies you have to take on faith; they are properties you can test.

Proofs: any fact, checked against the state root

Every block commits to a single cryptographic state root (a Jellyfish Merkle Tree root — the block's app hash). Any fact in state can be escalated to an ICS23 inclusion proof against that root: a compact proof that "this exact record is committed at this height," verifiable by a light client that holds only the root — no full node, no trust in the server that handed you the data.

The verification is not a re-implementation that might drift from the chain's: the chain, the wallet, and Karma all verify through one shared code path (the first-party ics23 verifier over jmt's spec). What the chain commits, any distrustful client checks with the same math.

Determinism and replay: don't trust the index, replay the chain

The state machine is deterministic by construction — no floating point, no wall-clock, no unordered iteration into committed state — so every honest node computes a bit-identical result and the same app hash. That has a strong consequence for trust:

Karma, the read side, holds nothing of value that the chain doesn't. Delete it and it rebuilds byte-for-byte by replaying the chain. So a graph answer you don't want to trust can always be re-derived from the chain yourself — and any single fact it returns can be escalated to a proof (above). You never have to trust the convenience layer; you can always fall through to the chain.

Content-addressed code: don't trust the gateway

Chain Resources — packages, documents, and eventually repositories — keep the manifest on-chain (per-chunk hashes and a content_root) and serve the bytes off-chain. A client verifies every chunk against the on-chain hash, and the manifest itself proves against the state root. So a dApp installing a dependency — even over the network npm gateway — never trusts the server it downloads from; the integrity check is end-to-end and terminates at the chain. Releases are append-only: a published version is never unpublished, only visibly flagged.

One wire format, cross-checked

A transaction signed by the TypeScript wallet is byte-for-byte identical to what the Rust chain expects — proven against a committed signing vector with a drift-guard test that fails the build if the wire format ever moves. Clients are generated from the chain's own protocol definitions, so there is no separate, drift-prone SDK per language to trust.

Permanence: proofs that keep verifying

Impact is never pruned. There is no deletion path in the state layer, and the chain retains all blocks. A proof issued today still verifies years from now, because the record it commits to is still there. Permanence is what lets the record serve as durable memory — for people and for the AI agents that read it.

What you do still trust — stated plainly

Verifiability is not a claim of zero trust, and pretending otherwise would be the opposite of credible. Two boundaries are real and named:

  • Validators see plaintext state. During the vetted-validator era, node operators hold the state they validate, so granular privacy is a trust boundary, not yet a cryptographic guarantee — while existence and net impact position stay public by design. On-chain encryption with selective disclosure is a firm genesis gate; the honest posture until then is a known, vetted validator set, not open anonymous operation.
  • Consensus assumes an honest supermajority. Like any BFT chain, safety holds while more than two-thirds of validator power is honest — here power is assigned to vetted Entities, not bought, which is its own trust model with its own governance.

Everything else on this page you can check yourself.