Comparisons

We sit alongside cheqd and Indy — not against them.

An honest, side-by-side read of the AnonCreds VDR landscape. We’re generous to the alternatives because most of them are perfectly good for what they do.

Chain
KanonAny EVM (Besu 26.5 reference)
did:cheqdCheqd network (Cosmos)
did:indyHyperledger Indy
AnonCreds VDR
KanonYes — drop-in for Credo, no AnonCreds changes
did:cheqdYes — resource registry
did:indyYes — native
Org governance
KanonOn-chain lifecycle + RBAC + timelock
did:cheqdDID-level controller
did:indyTrustee / steward roles
Revocation primitive
KanonOn-chain mapping(credDef × credIdHash → status)
did:cheqdCKS RSA accumulator + tails file
did:indyCKS RSA accumulator + tails file
Wallet revocation work
KanonNone (verifier looks up status)
did:cheqdGenerate CKS non-rev witness
did:indyGenerate CKS non-rev witness
Optional ZK mode
KanonGroth16 (BN254) on EVM
did:cheqd
did:indy
Upgradeability
KanonUUPS proxies + timelocked admin
did:cheqdCosmos chain upgrade
did:indyLedger fork

Why you might pick which

vs did:cheqd

Same idea, different chain.

Both treat the chain as a tamper-evident store of AnonCreds objects. Kanon adds org-lifecycle governance and an EVM-native revocation primitive that avoids accumulator math. cheqd uses CKS accumulators just like classic Indy.

vs did:indy

Permissioned chain, AnonCreds-native — but more rigid.

Indy's trustee/steward governance is bespoke; Kanon uses standard EVM RBAC + timelock you can audit with OpenZeppelin-shaped tooling. Indy revocation pins you to the CKS-accumulator + tails-file model.

vs did:ethr

Key-centric vs organization-centric.

did:ethr binds DIDs to addresses — there is no concept of an issuing organization with members and governance. Kanon has that as a first-class on-chain object. For pseudonymous individuals, did:ethr is great; for regulated issuance, you need org-level state.

See it in code.