FAQ
Including the ones where the honest answer is a limit rather than a capability.
No. Identities are tokenised on your machine with an HMAC key we never receive, and proofs are generated from tokenised values. The engine holds results it computed, never the raw values that produced them.
No. Producing a false proof that passes verification is computationally infeasible, including for the institution that generated it. Altering one balance after commitment changes the Merkle root and verification fails.
Anyone. The verifier is a standalone binary that reads a bundle from disk. No account, no licence, no network call and no contact with us — so the result does not depend on our being available or honest.
The proof infrastructure is hash-based rather than built on elliptic curves, so it does not rest on assumptions a quantum computer is expected to break. It also means no trusted setup: no ceremony, no shared secret, nothing to destroy afterwards.
All thirteen run on the same engine. A second service is a schema and a rule set, not a second deployment, so adding one does not add infrastructure.
No. Verification runs on a standard laptop — no cloud, no GPU. Proving is heavier and runs on your own infrastructure, sized to your population.
Rules live in a signed bundle, not in the family. A changed threshold is a new bundle; the proof records which calibration ran, so a supervisor can tell one period from another.
Proof of reserve examines the asset side. This examines the population — which records were and were not evaluated. That is the side that fails, and no incumbent attests it.
One day. One proof. You decide what comes next.