Skip to content

Privacy, Verifiability & Security

Calimero runs fully peer-to-peer and needs no external ledger. Where verifiability matters, it can optionally anchor a proof to an external ledger — not to perform computation, but to provide a verifiable source of truth for:

  • Network membership (list of participants)
  • Roles and permissions
  • Verifiable state checkpoints

In this modular stack:

  • Calimero handles data collaboration and replication.
  • An optional external ledger provides immutability and verification for anchored proofs.
  • Other tools like zero-knowledge proofs (ZK) can extend privacy guarantees.

Calimero is a component of a broader privacy-oriented architecture — modular, composable, and adaptable to your needs.

flowchart LR
    DATA[Private user data] --> CONTEXT[Calimero context]
    CONTEXT --> NODE[Node runtime]
    NODE --> AUDIT[Replayable audit trail]
    CONTEXT -. membership and checkpoints .-> CHAIN["External ledger (optional)"]
    NODE -. selective disclosure .-> PROOF[Hashes / proofs / attestations]

    classDef lime fill:#14210a,stroke:#a5ff11,color:#f5ffe0,stroke-width:2px;
    classDef cyan fill:#0b2526,stroke:#39d0c8,color:#dcfffd,stroke-width:2px;
    classDef purple fill:#221133,stroke:#c084fc,color:#f7ecff,stroke-width:2px;
    classDef orange fill:#2c1805,stroke:#ffb54d,color:#fff2d6,stroke-width:2px;

    class DATA,CONTEXT lime;
    class NODE,AUDIT cyan;
    class PROOF purple;
    class CHAIN orange;
  • Contexts scope visibility — each context has shared CRDT state plus per-member private storage (#[app::private]).
  • Hierarchical identities — root keys issue client keys per device or integration; revocation cascades from the root.
  • Deterministic runtime — WASM apps run inside merod, so every state transition is deterministic and replayable.
  • Selective disclosure — events can reveal only hashed or redacted payloads while full data stays on the owner’s node.
  • Audit trail — every method call is tied to the caller via executor_id, enabling tamper-evident logs.
LayerWhat is verifiedHow
Context membershipWho can read/write stateSigned invites or role assignments, optionally anchored to an external ledger
State synchronizationCRDT merges, Merkle checkpointsNodes exchange proofs before accepting remote updates
Application integrityWASM binaries, configurationHashes compared during deployment, optionally anchored to an external ledger
User actionsCaller identity, authorizationSigned challenge/response over client keys + executor audit logs
Data accessPrivate vs shared storageStorage namespaces tied to caller identity, enforced in runtime
  1. Optionally anchor critical context membership changes to an external ledger.
  2. Enable event payload hashing when emitting sensitive data; share full payloads via authenticated channels only.
  3. Rotate client keys on a cadence and revoke stale devices at the root key level.
  4. Run periodic Merkle checkpoint comparisons across nodes to detect divergence early.
  5. Configure node monitoring (Admin Dashboard, Node Console) to alert on failed syncs or unauthorized method calls.
TopicReferenceWhy it matters
Hosted TEE, KMS, and attestationmero-tee, KMS & AttestationExplains secure-service execution, attestation evidence, and how hosted trust claims are verified
Runtime architecture & security modelcalimero-network/core – ArchitectureDetails on merod, networking layers, and verification primitives
Identity delegation & permissionscore/crates/authHow root/client keys, invites, and revocations are enforced
Context lifecycle & admin APIcalimero-network/merobox – WorkflowsManaging contexts, capturing Application IDs, production rollouts
Authentication & signing flowsCore reference siteSigned challenge/response and hierarchical key delegation
Advanced cryptography experimentscalimero-network/experimentsThreshold signing, multi-party custody, and ZK experiments

This page stays high-level. For full setup steps, audit procedures, and API details, follow the linked READMEs.