The term "on-chain KYC" has been showing up more often in the web3 space. Taken at face value, it brings to mind the idea of "putting identity verification data on a blockchain," but on its own the term is a bit unclear.
On-chain KYC is easier to understand if you think of it as one implementation of the broader DID/VC (Decentralized Identifier / Verifiable Credentials) framework. This article lays out that idea, then looks at a concrete way it could be implemented on a blockchain.
Background: Two Shifts Around Identity Verification
Digital identity verification has changed a great deal over the past few years. One shift is that the handling of personal data has become stricter year by year. The other is that, with the advance of generative AI, the authenticity of document images themselves has become questionable. With these two shifts combined, it's no longer enough to just keep information safe — it's also become important for a third party to be able to confirm that the information is genuine.
DID/VC is a technology being standardized amid this shift, and its adoption is spreading in public efforts around identity verification as well.
What On-chain KYC Actually Looks Like: Do eKYC, Issue a Credential, Reuse It
Applying the idea of DID/VC to identity verification (KYC) is what on-chain KYC really is. The flow looks like this:
- A user completes eKYC (online identity verification) with one provider
- Once verification is complete, the issuer issues a "verified" credential
- The user stores that credential in their own digital wallet (like Apple Wallet)
- When using another service, the user simply presents the stored credential, without submitting documents again, and verification is complete
The heavy work of identity verification only needs to happen once, and the credential obtained there gets reused across various services. This is the basic idea: DID/VC as a way to resolve the inefficiency of repeating KYC over and over.
A Concrete Implementation Image on a Blockchain
The concept alone can be hard to picture, so let's look at one implementation pattern.
Representing the "credential" as a token
One approach represents a "verified" status as a soulbound token (SBT) tied to the user's on-chain account. An SBT is based on the NFT technical standard (ERC-721), but designed so it cannot be transferred to another account. As the name suggests, it's "bound to the soul," unable to be separated from a specific account.
This is the point of contact between the DID/VC idea of "storing a credential in a wallet" and what the term "on-chain" refers to in implementation. If the credential itself exists as a token on-chain, a smart contract can reference that status directly and the credential is able to be used across several different applications.
At the time of issuance, only the fact that "the holder has a valid ID" is disclosed on-chain, and personal information such as name or date of birth is not disclosed on-chain — this design keeps privacy protected.
The issuance and revocation process
To receive the token, a user needs to go through KYC via an issuer (attestor). In practice this centers on verification using an official identity method (such as a My Number Card), and AML (anti-money-laundering) and PEP (politically exposed person) checks are also generally carried out.
The rough flow is as follows:
- The app prompts the user to issue the token
- The wallet requests the issuer to generate a message for signing
- The user signs it with their private key (done off-chain, so no gas fee is incurred)
- The issuer verifies the signature
- If there's no problem, the token is issued
After issuance, ongoing screening against sanctions lists and PEP databases continues, and if a concern is found, the issuer can be designed to revoke the token. Since a person's legal status can change, it's a desirable design for both the issuer and the user to be able to burn the token.
Reusability across chains
A token minted on one chain may serve as the source of truth, while other chains query that status via a bridge (interchain messaging) and receive it as a simple Verified/Unverified boolean.
This is precisely the mechanism that embodies DID/VC's idea of "reusability": using a single identity verification result across multiple applications and multiple chains.
Balancing privacy and compliance
Another interesting use case is combining this with privacy protection protocols. Because public blockchains are designed so that transactions are visible to everyone, this raises privacy concerns for entities handling sensitive transactions. At the same time, such anonymization technologies have also been misused for money laundering in the past.
This is where the idea of an "inclusion proof" comes in, proving that a specific account belongs to a set of accounts that satisfy compliance. Using a verified token, this inclusion proof can be provided at low cost, without including any personal information at all. Compliance and privacy can both be achieved just by checking whether an account holds a valid token.
Looking again at the token-based implementation, the direction DID/VC is really aiming for becomes clear. The key points are being able to secure tamper resistance while disclosing only the minimum necessary information, and being able to bridge information between different services and different chains in a way that's verifiable as genuine.
Though the technical vocabulary differs, the underlying structure of this implementation — an issuer performs identity verification and issues a credential, the credential is tied to the user's account (wallet), the credential is difficult to tamper with or forge and can be verified by a third party, and a single verification result can be reused across multiple applications — overlaps with the thinking behind DID/VC.
Where Does the Blockchain (On-chain) Actually Come In?
In the token-based implementation described above, what stands out is that the credential (status) itself is represented as a token on-chain. That said, personal information such as name or date of birth is not itself written onto the chain. What's on-chain is nothing more than a minimal state, Verified or Unverified. This design principle — personal data stays off-chain, and only verifiable state information goes on-chain — is the axis of the thinking that secures verifiability while protecting privacy.
