How many times will you prove you are over 18 this year? Each time, somewhere, a copy of a document that says a great deal more than that is stored, insured against breach and eventually audited. Conventional onboarding charges for trust every time it is needed, at roughly €70 to €100 per user once document capture, liveness checks, sanctions screening, manual review, storage and failed-upload drop-off are counted. Regulation is now pricing the other side of that ledger. GDPR, India’s DPDP Act, Indonesia’s PDP law and the UK Online Safety Act all push companies to ask what data they actually need to hold while eIDAS 2.0 requires every EU member state to offer citizens a digital identity wallet by December 2026. Deepfake volumes have gone from roughly half a million to a projected eight million in two years while human detection has fallen to something close to a coin flip, which turns the question of who is acting on the other side of a screen from a compliance detail into a board-level risk.
Moca Network is Animoca Brands’ answer to that question. It is the identity layer connecting a portfolio of more than 600 companies and over 700 million addressable users, built around the AIR product suite, which stands for Account, Identity and Reputation and gives an app a universal embedded account into which trusted parties can issue verifiable credentials that the user carries elsewhere. Its largest deployment is with SK Planet, operator of OK Cashbag, South Korea’s largest integrated rewards programme, which has integrated AIR Identity across roughly 29 million users and 95,000 merchants. I sat down with Cham, who leads product at Moca Network and has worked across Moca ID, the $MOCA launch and now AIR, after eight years in finance, the CFA Program, a crypto fund started in 2017 and a stretch in performance marketing before NFT launches brought him to Animoca.
Ishan Pandey: Hi Cham, it’s a pleasure to welcome you to our “Behind the Startup” series. Please tell us about yourself and the journey that led you to Moca Network and AIR.
Cham: Hi Ishan, pleasure to be on.
I’m Cham, and I lead product at Moca Network, where our core offering is the AIR product suite. The problem I spend most of my time on is identity fragmentation: users keep proving the same things repeatedly, enterprises keep storing data they would rather not hold, and agents are starting to act on behalf of people.
My path here was not planned. I started in finance, spent eight years there, and completed the CFA Program. That gave me a useful view into how large institutions think about trust, risk and compliance. However, on the side, I was always trying to build things—dropshipping, affiliate marketing, programmatic trading, and eventually a crypto trading strategy that led me to start a fund in 2017.
Crypto winter wore me down, so I moved into ad-buying and performance marketing as “sushiparlour.” Then the 2021 bull market and NBA Top Shot pulled me back into crypto through NFT launches, which eventually led to Animoca and then Mocaverse, now Moca Network.
Since then I’ve worked across Moca ID, the $MOCA launch, and now AIR. In hindsight, the through line is trust: finance taught me how institutions manage it, marketing taught me how incentives move people, and Web3 showed me what happens when users can carry assets and identities across networks. AIR is where those threads meet.
Ishan Pandey: You sit at an unusual vantage point, building identity products inside an ecosystem with hundreds of portfolio companies and a very large addressable user base. From that seat, how has the conversation with platforms about identity changed over the past three to five years, and when did digital identity stop being a compliance line item and become a board-level topic?
Cham: A few years ago, decentralized identity was still abstract. Most platforms either did not understand why they needed it, or treated it as a narrow KYC / anti-bot tool for exchanges, onboarding and airdrops.
That changed because the pressure became practical. Regulation made storing personal data more expensive. eIDAS 2.0, GDPR, DPDP, Indonesia’s PDP law and the UK Online Safety Act all push companies to ask what data they actually need. At the same time, AI and deepfakes made “Who is acting here?” a board-level risk question.
So enterprises are no longer asking, “What is decentralized identity?” They are asking, “How do I verify without repeating KYC, prove age without collecting a document, reduce breach surface, and authorize an AI agent without giving it unlimited access?”
Big tech is moving toward wallets, passkeys and device-bound credentials too, but usually inside closed ecosystems. For enterprises, the strategic question is whether identity becomes another platform dependency, or whether they build around a portable trust layer that works across apps, wallets, partners and agents.
That is the shift: identity is no longer just compliance infrastructure. It is becoming product, risk and eventually revenue infrastructure.
Ishan Pandey: eIDAS 2.0 requires every EU member state to offer a digital identity wallet by December 2026, and fewer than a third are assessed as ready. Deadlines in technology regulation have a habit of slipping quietly. What actually changes for a platform on the other side of that date, what does readiness genuinely require, and what should a company that has not started be doing this quarter rather than next year?
Cham: I would not build a strategy around whether the exact date slips. With broad regulation, implementation will vary and enforcement may take time. But the direction is clear: user-held credentials are becoming mainstream infrastructure.
The real change is expectation. Once users can prove things through national wallets, banks, or telcos, they will ask why every new platform still needs another passport scan, selfie, or proof of address.
Readiness is not just “Can we accept an EUDI wallet?” Readiness means knowing what claims you need, who you trust to issue them, how users present them, how you verify or revoke them, and how much raw personal data you can stop storing.
This quarter, map the personal data you collect. Then pick one high-reuse claim, over-18, KYC-passed, residency, loyalty tier and pilot it as a credential. Don’t wait for every member state to be ready. By then, others will already be learning from production.
Ishan Pandey: The onboarding economics are the part of this story that seems to persuade finance teams fastest, with wallet-based reusable credentials taking know-your-customer cost from roughly €70 to €100 per user down to €3 to €8. Can you walk us through where that money actually goes in a conventional flow, which parts of it a reusable credential removes rather than merely shifts, and what platforms consistently underestimate when they model the change?
Cham: I would be careful with any universal KYC cost number because each market and provider is different. But directionally, the economics are clear: the old model charges every time you need trust; reusable credentials let you create the trust signal once and verify it many times at a much lower marginal cost.
The old cost is not just “checking an ID.” It is document capture, liveness, database checks, sanctions screening, manual review, fraud ops, storage, audits, support and failed-user drop-off. Every repeated selfie or failed upload loses users before they reach the product.
Reusable credentials do not remove the first trusted check. They remove the repeat. Once KYC-passed, over-18 or another claim becomes a credential, the next platform can verify the proof instead of collecting the passport scan again.
That is not just cost-shifting. It changes the unit economics from repeated document collection to reusable proof. The issuer can be compensated, the verifier gets a cheaper check, and the user avoids another painful onboarding flow.
What platforms underestimate is the operating model: useful claims, trusted issuers, freshness, expiry, revocation and UX. They also underestimate the value of not holding the raw data. Reusable credentials do not make trust free; they make trust portable.
Ishan Pandey: On the technical side, could you explain what actually happens when a verifiable credential is issued and then presented. Who signs what, what a verifier receives compared with what an issuer holds, and how selective disclosure lets a user prove they are over 18 without the age, the date or the document ever crossing the wire. Why does this change the breach surface structurally rather than incrementally?
Cham: With AIR Identity, the issuer remains the source of trust. The issuer keeps the source data, controls the signing, and decides what claim it is willing to stand behind — KYC-passed, over-18, membership status, loyalty tier, education status and so on.
AIR provides the rails: the account, encrypted credential infrastructure, verification programs and SDKs. But the important point is consent. The credential is encrypted to the user, and the data only flows when the user authorizes it, because the private key tied to that user is required to decrypt and present the data for use.
At enterprise scale, this can still happen without forcing a new wallet ceremony. If a user already completed KYC, onboarding, purchase or membership verification, the enterprise can issue the credential to that user’s AIR Account, but later usage still depends on user consent and the user-controlled private key path.
On presentation, the verifier asks for a specific proof. If it only needs “over 18,” it should not receive the birth date or passport scan. If it only needs “KYC passed,” it should not receive the full identity file.
That changes the breach surface structurally. In the old model, every verifier becomes another database of passports and selfies. In this model, the verifier can choose to hold only the proof it needs, not the underlying document. Personal data should not go on-chain; the chain and verification layer are for trust, status, proof verification, revocation and settlement logic.
Ishan Pandey: Your commercial argument inverts the usual one, treating held data as a liability and verification as a revenue line. Take us through the mechanics of that: who issues, who verifies, who pays whom, and what a platform sitting on years of user records has to do before it can turn any of that into a credential someone else will pay to check. Where does that model break down?
Cham: The issuer is the party with the trusted relationship and useful data: a bank, telco, KYC provider, loyalty platform, university, game or marketplace. The verifier is the party that needs access to data and confidence in that data to make a decision.
An important point is that the verifier often does not need the full data. They may only need a proof: over-18, KYC-passed, eligible for a campaign, or membership tier. The user controls whether they present that credential, what they disclose, and to whom.
That is the commercial inversion. Held personal data is increasingly a liability. A trusted, consented, reusable claim can become an asset. The issuer monetizes trust and data retention, while the verifier pays for what it needs, and the user gets a better experience.
But a platform cannot just wrap its database and call it a credential network. It needs to decide which claims are useful outside its own walls, which ones it is trusted to issue, what incentive the user has to share them, how the credential is issued, and how it can be revoked.
The model breaks if there is no verifier demand, if the issuer is not trusted, or if users have no reason to present the credential. A raw database row has limited value. A specific, consented, revocable claim has value.
Ishan Pandey: Deepfake volumes have gone from roughly half a million to a projected eight million in two years while human detection has fallen to something close to a coin flip. You argue that detection is an arms race that defenders lose by definition and that the durable answer is proving authenticity at the source. What does verification at the source mean operationally for a platform running an onboarding flow today, and what does it not solve?
Cham: Detection is always a cat-and-mouse game. The better detection gets, the more incentive attackers have to build better synthetic identities, documents and deepfakes. So I would not frame this as one perfect “proof of humanity” check.
Proof of humanity is one signal. Platforms also need KYC status, account age, transaction history, app activity, loyalty behaviour, device reputation, payment history and credentials from trusted issuers.
Verification at the source means trusted parties issue claims about what they actually know. A bank can attest to KYC. A telco can attest to account tenure. A game can attest to years of activity. A marketplace can attest to seller reputation. None is perfect alone, but together they are much harder to fake than one selfie check.
That is why I see this as user-data enrichment, not just identity verification. The user carries richer, consented, reusable signals, and each platform decides what level of confidence is enough for its use case.
It does not replace fraud systems or platform judgment. It does not solve the first unknown user, a compromised issuer, or social engineering. It just moves the question from “does this look real?” to “what trusted history supports this account being real enough for this action?”
Ishan Pandey: Running AIR Wallet across roughly 28 million users at SK Planet is a different exercise from running a standards-compliant pilot. What did production at that scale teach you that the specification did not, where did user behaviour diverge from the design assumptions, and what did you have to change as a result?
Cham: Production at that scale teaches you that the spec is only the starting point. It does not tell you how many Android edge cases you will hit, how many user journeys break on real devices, or how much you need to abstract before the product feels natural.
The biggest lesson is that you cannot lead with Web3 complexity. Most users are not thinking about wallets, credentials or sovereignty. They care whether the experience is useful, fast and worth the effort. So you hide the chain, gas and seed phrase, and make it feel like a feature inside an app they already understand.
The other lesson is consent. In theory, everyone agrees users should understand what they approve. In practice, most people do not read OAuth scopes or expand permission details if the incentive is attractive enough. We already see that with AI agents connected to email, calendars and drives.
So the design challenge is balance: educate users, but do not make the permission flow so heavy that they drop off or blindly click through. At scale, good identity design should be simple, scoped and revocable — and almost invisible until the user actually needs to decide.
Ishan Pandey: Every trust stack we have, covering identity, authorisation and accountability, was built for humans. As AI agents start to shop, pay and negotiate as economic actors, someone has to answer whether an agent is what it claims to be and whether it is authorised to act. Which parts of that problem does a credential model genuinely extend to today, and which parts are still open research rather than shippable product?
Cham: I would separate agent identity from agent authorization.
Agent identity itself is still open research. With humans, we have sticky anchors: biometrics, government IDs, financial history and long-lived accounts. With agents, that is less clear. If I can swap the model, tools or capability with a click, what exactly is the immutable identity — the model, wallet, developer, operator, policy or runtime?
What is shippable today is operator-linked delegation. The operator, a human or organization, already has identity, reputation and permissions. The practical question is how to extend that authority to an agent in a scoped, consented and revocable way.
A credential model helps the agent prove it is acting for a specific user or organization, and only for a specific context. Not unlimited access. Not the keys to everything. Just a bounded authority to do a defined thing.
What remains open is broader accountability: agent-to-agent negotiation, shared standards, proving actions stayed in bounds across many hops, and liability when the user, agent, model provider and platform all touch the transaction. We should not pretend agent identity is solved just because an agent can hold a key.
Ishan Pandey: Finally, for founders and platform teams watching the December 2026 date approach while still running document uploads and storing personal data they would rather not hold, what is the most practical advice you can give them this quarter?
Cham: Work with us of course! 🙂
But in all seriousness, start by listing the personal data you hold and asking whether you really need it. Many companies store documents because that was the easiest onboarding flow, not because the business needs to keep the file forever.
Then ask: do we need the raw data, or only a proof derived from it? Date of birth is a simple example. In many flows, you do not need the full birth date. You need to know the user is over 18.
Pick one flow and replace the raw data with the narrowest proof possible. Ask for over-18 instead of DOB. Ask for KYC-passed instead of another passport scan. Let a trusted issuer stand behind the result.
Most companies should not rebuild wallet and credential infrastructure from scratch. Work with providers that handle standards like OID4VP, and focus on what you actually need to know, what you can stop storing, and what creates a better user experience.
If you only do one thing this quarter: choose one piece of personal data, replace it with a proof, and pilot that flow. Do not wait for December 2026 to start learning.
Don’t forget to like and share the story!
Vested Interest Disclosure: HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR.