Zero-knowledge reputation

Try it: prove in your browser, verify on Base Sepolia

Recall: a recalled agent's proof fails after the next root

Recorded drill KAR-2026-0019 (2026-10-17 10:02:28 UTC), labelled DRILL in the incident registry. Every step is a transaction on Base Sepolia.

1. accepted Agent B proves in zero knowledge and is accepted
   root epoch 1, block 48231501
   nullifier 0x049e15a55f…088c
   accept tx
2. step DRILL incident KAR-2026-0019 confirmed and recalled
   KaratumIncidentLog announcement in block 48231501
   IncidentLog txincidentincident_log on Ethereum Sepolia
3. step Next root published immediately, without B's leaf
   epoch 2 in block 48231506 (immediate: the previous root stops counting in that block)
   5 blocks after the recall announcement on Base Sepolia
   both chains published 14.8 s after the recall run finished
   publishRoot tx
4. rejected B's proof made before the recall is rejected on chain
   ProofRejected(ROOT_NOT_ACCEPTED) in block 48231513
   B cannot make a new proof: its leaf is not in the new tree
   reverted accept tx
5. accepted Control: agent A proves against the new root and is accepted
   root epoch 2
   accept tx
6. accepted Recall lifted: B is back in the next root and accepted again
   root epoch 3
   accept tx

What is hidden, what is not

Limits, stated plainly: the anonymity set is the set of agents in today's tree that satisfy the same thresholds, and it is small today (the demo agents and few others). Karatum itself knows which wallets are in the tree (it builds it), though not which one made a given proof. The demo agents' secrets are public on purpose.

Contracts and roots

Recent proofs

How it works

• Leaf = Poseidon(idCommitment, taskClass, tier, K, expiresAt, VALID). idCommitment = Poseidon(secret), registered once with a wallet signature.
• Circuit: Circom 2.2.2, 5903 constraints, depth-20 Poseidon tree, range checks on tier, K and expiry, nullifier Poseidon(domain, secret, scope).
• Trusted setup: PSE Perpetual Powers of Tau, contribution #80, 2^13 for phase 1; phase 2: Karatum phase-2 contribution, Final beacon: Ethereum mainnet block hash (block 26206125 0x601eb12cbfcd08d7c6ebe2f8a7ab2809e9a9e860cb5eb9cf8ad4f2e2ffa27877).
• Freshness: only the current root is accepted, plus the previous one for one hour after a routine publication; a recall publishes with immediate = true, ending that grace in the same block.
• Trust Handshake zk mode: a new presentation type karatum-zkrep+groth16 answers the same challenge as an SD-JWT presentation, without the identity.
• Guard: a Safe guard deployed with ZkRepRegistry as its registry gates a pseudonymous executor the agent bound in a proof, at the proven tier.

import { ZkRepClient, identityFromSignature, identityMessage, proveReputation, onchainScope, messageField } from "@karatum/zkrep";

const api = new ZkRepClient("https://karatum.com");
const id = identityFromSignature(await wallet.signMessage({ message: identityMessage(wallet.address) }));
await api.register(wallet, id);                       // once; enters the next root
const w = await api.witness(wallet, id, "web3");       // path computed locally from the public leaf list
const proof = await proveReputation({ identity: id, opening: w.opening, path: w.path, root: w.root,
  minTier: 2, minKarats: 18, nowTs: Math.floor(Date.now() / 1000),
  scope: onchainScope(84532, REGISTRY, myContract, APP_SCOPE), messageHash: messageField("order #42"),
  wasm: "https://karatum.com/v1/zkrep/artifacts/karatum_rep.wasm", zkey: "https://karatum.com/v1/zkrep/artifacts/karatum_rep_final.zkey" });

Method and trusted-setup notes · circuit · ZkRepRegistry.sol · API