KILT Protocol: Unleash Self-Sovereign Identity on Polkadot (2025 Guide)
KILT Protocol is Polkadot’s self-sovereign identity (SSI) parachain for issuing W3C-style decentralized identifiers (DIDs) and verifiable, revocable credentials. This guide explains how KILT works, why builders choose it on Polkadot, how to ship a DID + credential flow with Sporran/web3name/DIDsign, and where KILT is used in production.
What is KILT Protocol? (and ELI5)
KILT is a Polkadot parachain purpose-built for decentralized identifiers (DIDs) and verifiable, revocable credentials. Credentials are held by users, not platforms; on-chain you anchor minimal data (hashes/status), preserving privacy and enabling revocation. ELI5. Imagine your wallet holds cards (driver’s license, membership). With KILT, the “cards” are digital credentials in your Sporran wallet; you show just what’s needed (e.g., “over 18”) while a verifier can check it’s legit—without ever copying your personal data.
Why Polkadot? Shared security & XCM
KILT runs as a Polkadot parachain, inheriting shared security from the Relay Chain and gaining native cross-chain messaging (XCM) to reach other parachains/apps. This lets identity actions interoperate across the ecosystem without custom bridges.
Core concepts
DIDs: light vs full
- Light DID: created locally (off-chain), good for many uses.
- Full (on-chain) DID: anchored on KILT for on-chain actions (write CTypes, attestations, delegations, key rotation). Creating one requires a refundable deposit (~2 KILT), which you can reclaim by deleting the DID.
Note: KILT supports DID keys for authentication, encryption, attestation, and delegation.
CTypes, credentials, attestations & revocation
- CTYPE: JSON schema defining what a credential claims (e.g., “Over-18”).
- Credential: user-held data matching a CTYPE.
- Attestation: hash of the credential written on-chain by an attester; enables revocation and timestamping while the actual personal data stays off-chain.
Wallet & tools: Sporran, web3name, SocialKYC, DIDsign
- Sporran: browser wallet for KILT coins, DIDs & credentials.
- web3name (w3n): human-readable handle bound to your DID; can link addresses across KILT/Polkadot/Ethereum (via w3ndi).
- SocialKYC: issues credentials after you prove control of social accounts/email—privacy-preserving alternative to centralized logins.
- DIDsign: decentralized document/file e-signing & verification using your on-chain DID; supports multi-sign and timestamping.
How KILT works (issuer–holder–verifier)
- Holder requests a credential from an Issuer/Attester (e.g., “age over 18”).
- Issuer checks evidence, creates credential for the holder, and anchors a root hash on KILT.
- Verifier receives a presentation from the holder, checks signature + that the on-chain attestation exists and is not revoked.
- If requirements change, issuer revokes (and can remove) the attestation on-chain.
In the wild: production use cases
- Deloitte (Switzerland) – Reusable KYC/KYB credentials built on KILT (live since 2023), designed for banking-grade compliance while keeping user data off-chain and under user control.
- Polimec – Fundraising platform on Polkadot uses reusable KYC credentials anchored on KILT to enable compliant participation and privacy-preserving verification.
- web3name in Nova Wallet – Link a w3n to addresses across Polkadot, Ethereum, Bitcoin via w3ndi for human-readable transfers and identity.
Mini-guide: ship a DID + credential flow
Prereqs: Chrome/Firefox, Sporran, small KILT balance (or Checkout Service).
- Install Sporran & create a light DID.
- Upgrade to a full DID (deposit ≈ 2 KILT; refundable on deletion).
- Claim a web3name (requires full DID + small tx fees).
- Obtain a credential (e.g., SocialKYC or enterprise issuer).
- Present the credential to your app via KILT SDK; verify on-chain attestation + status.
- (Optional) Sign files with DIDsign and share the signature/metadata bundle for independent verification.
Practical example: Investor onboarding on a Polkadot dApp: Require a “KYC-Passed” credential from a recognized attester (e.g., Deloitte). Your verifier checks the user’s presentation + attestation status on KILT; store only the attestation reference and your own access decision—no personal data retained.
Comparison: KILT vs Heima vs Polygon ID
| Tool/Protocol | DID/VC model | Privacy model | Revocation | Interop & stack | Typical use cases |
|---|---|---|---|---|---|
| KILT Protocol | W3C-style DIDs (light/full) + VCs; on-chain attestation hash | Off-chain data; on-chain hash & status | On-chain revocation/removal by attester | Polkadot parachain, shared security, XCM; tools: Sporran, web3name, SocialKYC, DIDsign | KYC/KYB, age/role proofs, enterprise doc signing, cross-ecosystem identity |
| Heima | DID aggregation + VC issuance | Privacy via TEEs + IdentityHub | VC issuance & identity scores; off-chain aggregation | Substrate/Polkadot; cross-chain reputation | Reputation, airdrops, credit scoring, identity graphs |
| Polygon ID | Iden3 DIDs + ZK proofs | Zero-knowledge selective disclosure | ZK-friendly revocation models | EVM/Polygon; OIDC/Verite integrations emerging | Private on-chain checks (e.g., “over 18”) without revealing PII |
Common pitfalls & tips
- Don’t confuse light vs full DIDs. On-chain actions (attestations, delegations, w3n) require a full DID (refundable deposit).
- Linked accounts aren’t for transfers. When linking an Ethereum account to your DID, don’t use that link itself for asset transfers—use the actual address.
- Design revocation early. Decide whether you need “mark-as-revoked” or “revoke & remove”; wire this into issuer workflows and verifier checks.
- Minimize on-chain writes. Keep PII off-chain; anchor only hashes/status to save fees and preserve privacy.
- OIDC bridges. You can place DIDs/VCs behind familiar OpenID Connect sign-in flows; this helps Web2 apps adopt SSI without rebuilding auth.
FAQs
1) Is user data stored on chain? No. Credentials live off-chain with the user; the chain anchors a hash + status (attestation) to enable verification and revocation.
2) What’s the difference between a light and full DID? Light DIDs are local/off-chain; full DIDs are anchored on KILT and unlock on-chain actions (CTypes, attestations, delegations). Full DIDs require a refundable deposit.
3) How do revocations work? The attester writes/updates attestation status on KILT. Verifiers check the presented credential against the on-chain attestation and its current status.
4) Do I need KILT coins to start? Yes for on-chain operations (fees/deposits). For end users, Checkout Service can anchor a DID and let you pay with fiat while keeping keys on your device.
5) Can I use KILT identity across Polkadot and EVM? Yes. web3name can link addresses across Polkadot and Ethereum (via w3ndi). DIDsign and credential flows are chain-agnostic from the verifier’s POV.
6) Why build on Polkadot? Parachains inherit shared security and use XCM to interoperate—ideal for identity that many chains/apps must trust.
7) Is Deloitte really using KILT? Yes. Deloitte Switzerland announced and shipped reusable KYC/KYB credentials on KILT in 2023.
8) Can I sign PDFs/contracts with my DID? Yes. DIDsign enables decentralized signing and verification of files, including multi-sign workflows with timestamps.
Conclusion
KILT gives builders a standards-aligned, privacy-first identity layer with revocation, delegations, and interoperability baked in. Running on Polkadot means shared security and easy cross-chain reach. If you’re shipping compliance-sensitive dApps (fundraising, fintech, enterprise workflows) or simply want portable identity for your users, KILT is battle-tested and ready.