Going Back in History? "On-chain KYC" May Be a Detour for Web3

Author: Loopy Lu, Odaily Planet Daily

Original article: “Why I Say 'On-chain KYC' Might Be a Misstep for Web3”

Recently, Galxe (formerly Project Galaxy) announced the launch of Galxe Passport. Galxe claims that this project can serve as a universal identity for users in Web3, capable of securely and anonymously storing identity information. This initiative also borrows from the popular concept of "soul binding," with the Galxe Passport existing in wallets as an SBT.

However, after its launch, the project sparked widespread discussion within the community, with conversations about this initiative spreading and extending to similar projects.

After practical experience, Odaily Planet Daily found that minting a Galxe Passport requires users to provide identity IDs, such as ID cards or passports. If you are not among the first 100,000 users to mint, this SBT even requires users to pay a fee of $5 as a certification cost.

There is no doubt that Galxe Passport attempts to collect user identity information and perform KYC verification on wallet addresses.

Coincidentally, Galxe is not the first to do this. Recently, Binance announced the launch of the first soulbound token (SBT) on the BNB Chain: the Binance Account Bound (BAB) token, which serves as proof that Binance users have completed KYC verification, and unverified KYC users cannot mint it. This token is non-transferable and unique.

Is SBT Naturally Suitable for KYC?

Some time ago, Vitalik Buterin published an article about "soul binding," bringing NFTs into a new realm that had not been explored. Although many feasible use cases for SBTs were proposed, such as trustworthy reputation data, skill certificates, and better POAPs, most of these more practical use cases remain experimental and are still far from reality.

Currently, the most widespread SBT use cases are likely Binance's BAB and Galxe Passport. These two are highly similar: they are both on-chain KYC.

The characteristics of SBTs determine that they can be used to store or prove certain information. Formally, this token serves as KYC, making it practical and convenient.

At present, Web3 lacks native on-chain KYC solutions. When project parties conduct "real person" verification, they often rely on Web2-based verification methods to indirectly achieve real person verification. For example, verifying Twitter accounts, Discord accounts, etc. This fundamentally relies on centralized Web2 infrastructure and has certain limitations.

Perhaps for this reason, using SBTs for on-chain KYC has become a favored track for multiple project parties. It seems that project parties in the crypto world genuinely need a crypto-native identity solution. However, there are currently no good options available in the market.

Does Wallet Address Need KYC?

As project parties attempt to issue KYC for our wallet addresses, a more critical question may deserve our attention: Does a wallet address need to undergo KYC?

In the entire crypto world, KYC is fully necessary. This is important for compliance, regulation, investor protection, and many other fields.

Decentralization is the cornerstone of the crypto world, and the account system built using wallet addresses as identity IDs has been operating stably for a long time. Terms like "trustless" and "decentralized" are not just empty words; through the long-term efforts of builders, crypto natives have truly constructed a free world on-chain without the need for bank cards and passports. Smart contracts, DeFi, NFTs, and technological advancements have allowed the decentralized world to operate smoothly.

Naturally, a KYC-free order also has its downsides. For example, community governance becomes more difficult, fake accounts proliferate, and there may be risks of witch attacks. However, the industry is working hard to address these issues through various means. Conducting KYC on wallet addresses may be one of the worst choices among them.

Worse than Asset Theft is Identity Theft

Conducting KYC verification on wallet addresses is not a one-size-fits-all solution. It may even produce completely opposite negative consequences.

In centralized platform KYC, it seems that nothing too terrible happens. But this is precisely due to "centralization," rather than an inherent advantage of KYC.

After KYC on a centralized platform, if a security incident such as password loss occurs, users can freeze or lock their accounts based on their identity and confirm the ultimate ownership of the account. After KYC, users are "verified." Although the data is held by a centralized platform, relying on centralized processes, users' ownership and identity are indisputable; all centralized data can be frozen, retrieved, or canceled.

For the platform, it can also grasp user identities, meet compliance requirements, confirm user authenticity, and eliminate bot interference, etc. Conducting KYC verification on centralized platforms is not necessarily a bad thing.

But what happens when this process moves on-chain? The ownership of a wallet is not guaranteed by a centralized institution based on identity documents but is entirely controlled by private keys. This also means that KYC almost loses its greatest significance: confirming user authenticity.

Although SBTs are non-transferable and cannot be traded, wallet addresses can be shared. If using a smart contract wallet, wallet addresses can even facilitate ownership transactions.

If a user utilizes an on-chain address that is not KYC'd in their name, the outcome could be disastrous. For project parties, the first issue is that the user data obtained by the protocol may become distorted. Since the actual controller of the address can change, the user's actual on-chain behavior may differ significantly from the behavior associated with the bound address.

For users, due to the characteristics of SBTs, this KYC cannot be eliminated or even transferred. Once a private key leak occurs, what users lose is not just their assets; they may also lose their identity, which is an especially terrifying consequence.

What Other Issues Exist?

Additionally, data security issues also deserve significant attention. After users perform operations like KYC on-chain, where is their sensitive identity information stored?

In the future, with the evolution of technology (and the increasing KYC requirements from project parties), will our fingerprints, faces, and documents all need to be submitted to project parties? Undoubtedly, the transmission and storage of this data remain Web2-based. Even though we obtain SBTs as data credentials, the risks to data security are still a Web2 issue. Furthermore, project parties still face significant moral risks regarding user data—no one knows how these data will be utilized by the project parties.

There is no doubt that on-chain KYC is a Web2-style data collection action wrapped in Web3 data credentials. This is far from the Web3 ideal of users having data sovereignty.

In the crypto world, we typically have more than one wallet. A single address cannot represent a user and faces risks such as address changes and private key losses. Encapsulating user identity information within a specific on-chain address results in distortion. The data behavior of a single on-chain address often cannot fully represent the user themselves.

Although the crypto world needs a trustworthy identity system, a more reliable DID, is conducting KYC on wallet addresses truly the best choice? The battle against identifying and forging false identities continues, yet no project party dares to boldly require users to "present ID to receive airdrops."

Web3 promises this—a free, open, permissionless decentralized internet.