Web3 · Engineering
Decentralized Identity & ZKP
Most identity systems force a trade between proving who a user is and protecting what they reveal. Decentralized identity and ZKP development is the engineering practice that issues claims as W3C verifiable credentials a user holds, then proves them with zero-knowledge against a DID-anchored key, so a verifier trusts the claim without the raw data. We build the DID methods, credential layer, and ZK circuits that make it work.
- SedaxZKP + DID infrastructurepartner build we delivered
- W3C VCverifiable credential modelportable across identity systems
- Aadhaarlive eKYC integrationone angle, not the ceiling
In short
What is Decentralized Identity & ZKP?
Decentralized identity and ZKP development is a verifiable-credentials engineering service for teams that need identity proofs without exposing raw data. We build DID methods, W3C verifiable credentials, and zero-knowledge selective-disclosure circuits. We built the ZKP and DID infrastructure for our partner Sedax, including a live Aadhaar-scale eKYC integration that proves attributes without revealing the record.
What we deliver
Concrete artefacts, not capabilities
- 01
Verifiable credential issuer wired to your trusted source, including Aadhaar eKYC.
- 02
DID resolver and method, chain-anchored or key-based, in the W3C VC format.
- 03
Zero-knowledge circuits for selective disclosure of credential attributes.
- 04
Credential revocation, status registry, and holder wallet integration.
- 05
Operator dashboard for issuance, revocation, and audit-log review.
Key concepts
Key terms, defined
- Verifiable credential
- A verifiable credential is a tamper-evident digital claim, defined by the W3C, that an issuer signs and a holder stores and presents. A verifier checks the issuer signature cryptographically without contacting the issuer, so the raw record stays in the issuer's custody while the proof travels with the user.
- Decentralized identifier
- A decentralized identifier (DID) is a globally unique identifier that resolves to a DID document holding public keys and service endpoints, with no central registry required. DID methods such as did:ethr anchor to a chain, while did:key stay off-chain. The DID-anchored key is what a verifier uses to check a credential signature.
- Zero-knowledge proof
- A zero-knowledge proof is a cryptographic method by which one party proves a statement is true without revealing the data behind it. In identity work, a ZK circuit can attest that a holder is over 18 or resident in a state without disclosing the date of birth or address itself, keeping attributes private at verification time.
- Selective disclosure
- Selective disclosure is the ability to reveal only the specific attributes a verifier needs from a credential, hiding the rest. A holder can present proof of state residency without exposing the full address or identifier. It is implemented with zero-knowledge proofs or signature schemes built for partial revelation.
How we work
Engagement phases
Identity model & spec
We map the trust model first: who issues, who holds, who verifies, which attributes need proving, and what must never be disclosed. Where a regulated source such as Aadhaar is in scope, the UIDAI access pattern, KUA or AUA classification, residency, and consent flows are pinned here. The output is a spec engineering, compliance, and audit teams sign off before any code starts.
DID & credential layer
We build the DID resolver, the verifiable-credential issuer, and the verifier. Credentials follow the W3C VC data model with proof formats portable across identity systems. The DID method is chosen by context: chain-anchored where on-chain attestation matters, key-based where it does not. This is the layer we engineered with Sedax, whose ZKP and DID infrastructure we built end to end.
ZKP & selective disclosure
We write the zero-knowledge circuits so a holder proves a claim without revealing the data behind it: age over 18, residency, or a verified eKYC status. On our live Aadhaar integration that means proving an attribute without exposing the number or document. Hardening covers replay protection on signed attestations, enumeration rate-limits, and issuer key rotation.
Pilot & scale
We launch behind a feature flag with a controlled cohort. The operator dashboard surfaces issuance volume, verification latency, revocation activity, and audit-log queries. Verification is local against the issuer DID key, so it scales without a live call to the source on every check. The system ships ready for production workloads and the audit posture they require.
Tech stack
What we build on
- W3C VCStandards
- did:ethr / did:keyDID Methods
- CircomZK Circuits
- snarkjsZK Proving
- Aadhaar eKYCIdentity Rail
- SolidityAnchoring
- Node.jsIssuer
- PostgresAudit Log
- TypeScriptSDK
- W3C VCStandards
- did:ethr / did:keyDID Methods
- CircomZK Circuits
- snarkjsZK Proving
- Aadhaar eKYCIdentity Rail
- SolidityAnchoring
- Node.jsIssuer
- PostgresAudit Log
- TypeScriptSDK
Scope
When this fits and when it doesn't
| This fits when | This doesn't fit when |
|---|---|
| You need privacy-preserving identity: verifiable credentials and zero-knowledge proofs instead of raw data exchange. | You want a national-ID system built from scratch, an identity-source replacement rather than integration. |
| A regulated or eKYC-backed source such as Aadhaar must be provable without storing or re-sending the record. | Raw identity data must be stored on chain or in plaintext for analytics or business logic. |
| Consent, revocation, and audit logging are first-order requirements, not afterthoughts. | There is no compliance workstream and the engagement assumes a clean regulatory path. |
Related work
Shipped engagements
Related services
Adjacent engagements
- Web3
Smart Contract Development
Solidity, Vyper, and Move contracts engineered for third-party audit, with tests and monitoring.
- Web3
DeFi Protocol Development
Lending, perpetuals, yield, and vault infrastructure spec'd for third-party audit.
- Product Studio
SaaS Development
End-to-end SaaS builds with multi-tenancy, billing, and observability baked in.
Frequently asked questions
Decentralized identity lets a user hold their own credentials instead of a provider holding them. An issuer signs a W3C verifiable credential, the holder stores it, and a verifier checks the issuer's signature against a DID-anchored key with no call back to the issuer. The raw data stays in the issuer's custody while the proof travels with the user.
A zero-knowledge proof lets a holder prove a statement, age over 18, residency, or a verified eKYC status, without revealing the underlying data. We write the circuits so the verifier learns only the answer, not the document or number behind it. This is the ZKP infrastructure we built for our partner Sedax, applied on a live Aadhaar integration.
Yes. The DID and verifiable-credentials layer is portable across identity systems; Aadhaar is the most demanding integration we ship, not the only one. The same credential layer supports passport, driver-license, and institution-issued credentials. For Aadhaar specifically we integrate UIDAI eKYC, OTP, and offline QR through your authorized KUA or AUA registration.
We integrate against UIDAI's published interfaces, eKYC, OTP, and offline-mode QR, through your authorized KUA or AUA registration. We do not claim direct UIDAI partnership. The compliance and access registration is owned by your team or your KUA partner; we engineer against the access pattern they secure and document the integration cleanly for audit review.
Cost follows scope. The main drivers are how many credential types you issue, whether zero-knowledge selective disclosure is in scope, the DID method and chain anchoring, and the depth of any regulated-source or compliance workstream. We quote a fixed price after the spec phase, once the verification surface is set. We do not publish a flat rate.
Last reviewed · Reviewed by Metaborong engineering team
Tell us what you are building.
We build what large agencies under-deliver and freelancers can't architect, across Web3 protocols, AI agents, and SaaS products. Tell us what you are building. We will tell you how we would approach it, no pitch deck, no fluff, no commitment required.