AIR Kit Deep Dive: Is AIR Kit the Best ZK Identity SDK in Web3? A Developer's Hands-On Review

Web3 onboarding infrastructure just lived through its consolidation wave. Privy went to Stripe in June 2025. Web3Auth was folded into Consensys/MetaMask. Dynamic landed inside Fireblocks. Sequence went to Polygon Labs. Every wallet-as-a-service darling of 2023 is now a feature inside someone else's strategy, payments rails, institutional custody, a wallet ecosystem. \ AIR Kit is the odd one out. Built by Moca Network , the team behind building the world's biggest identity network, AIR Kit treats login and wallets as the on-ramp, not the destination. The destination is portable, verifiable, monetizable identity: credentials a user earns once and proves anywhere, across a claimed 700M+ addressable users spanning Animoca's 600+ portfolio companies and partners like SK Planet's OK Cashbag (28 million KYC'd users), OneFootball (200M+ users), Ubisoft, Magic Eden, and SK Telecom. \ how AIR Kit actually works Two services, one account AIR Kit ships as a Web SDK (JavaScript) and a Flutter SDK , split into two independently adoptable services: \ Account Services handles authentication and wallets. A user signs in with email, social, or an existing wallet through a hosted widget; behind it, AIR Kit creates (or fetches) an embedded smart-contract account. The account abstraction layer supports session keys and gas sponsorship via paymaster, the user's first transaction can be gasless, plus built-in swap and on-ramp UI , so consumer teams don't assemble that plumbing from three vendors. Notably for teams with existing auth: AIR Kit supports bring-your-own-authentication (BYOA) , layering the AIR account and SSI identity on top of your current login rather than replacing it ( moca.network ). \ Credential Services is the differentiator: issue, store, and verify zero-knowledge verifiable credentials . An issuer attests to a fact about a user ("KYC passed", "age ≥ 18", "completed 50 ranked matches"); the user holds that credential in their AIR account; any verifier can later check a predicate on it and receive only a binary answer, Compliant or Non-Compliant plus a transaction hash. The raw data never moves. \ How login actually works The docs' own sequence diagram is worth internalizing because it shows how much a single call orchestrates. Your app calls airService.login() ; the SDK renders the hosted login UI (email/social/wallet), on successful auth it creates or fetches the user's smart account on Moca Chain and it returns a session plus an EIP-1193 wallet provider your existing wagmi/viem code can consume. One method, four systems coordinated. \ \ [IMAGE 5 — Account Services sequence diagram] import { AirService, BUILD_ENV } from "@mocanetwork/airkit"; const air = new AirService({ partnerId: process.env.NEXT_PUBLIC_PARTNER_ID! }); await air.init({ buildEnv: BUILD_ENV.SANDBOX, enableLogging: true }); const session = await air.login(); // hosted UI: email / social / wallet const user = await air.getUserInfo(); // UUID, token, linked accounts if (!(await air.isSmartAccountDeployed())) { const { txHash } = await air.deploySmartAccount(); // paymaster-sponsored } const provider = air.getProvider(); // EIP-1193 → wagmi/viem/ethers React teams can skip even this via the official wagmi connector , @mocanetwork/airkit-connector . \ How a credential actually moves The architecture diagram from the docs maps the full stack, and it's the clearest way to explain the trust model. Your frontend talks to Account and Credential Services through the SDK. Your backend authenticates to Credential Services with a Partner JWT , a token you sign with a private key whose public half you publish at a JWKS endpoint registered in the Developer Dashboard . Every issuance and verification is validated against keys you control, there are no bearer API keys to leak. \ From there, the flow splits by concern: \ Issuance. Your backend (or client, with a server-signed JWT) calls issueCredential with schema-typed claims. The Identity Oracle anchors a hash of the credential to Moca Chain's EVM layer, tamper-evidence without data exposure. \ Storage. The encrypted payload goes to MCSP decentralized storage (Moca Chain Storage Providers, architecturally descended from BNB Greenfield), decryptable by user-held keys. The chain holds commitments; the storage layer holds ciphertext; nobody holds plaintext but the user. \ Verification. A verifier calls verifyCredential against a dashboard-configured program ("age ≥ 18"). The user's client generates a zero-knowledge proof over the credential; the system returns Compliant/Non-Compliant (or Revoked/Expired) and a transaction hash. If the user lacks the credential, a redirectUrl routes them to obtain it, a clean UX recovery path most ZK demos ignore. \ // Backend: mint a Partner JWT (kid must match your JWKS endpoint) const jwt = await generateJwt({ partnerId, privateKey }); // Client: run the ZK check const result = await air.verifyCredential({ authToken: jwt, programId: "c21hc030kb5iu0030224Qs", redirectUrl: "https://yourapp.com/get-credential", }); if (result.status === "Compliant") grantAccess(); // zkProofs + txHash attached The canonical mental model, straight from the docs : the bar-door check. Prove you're over 18; never show the passport. \ The chain underneath: oracle, zkTLS, and why an L1 at all \ Why does this need its own blockchain? Moca Chain's answer is four primitives that generic L1s don't ship natively ( Moca Chain docs , moca.network ): \ A cross-chain identity oracle , relayer-compatible, so credentials anchored on Moca Chain can be verified from 25+ other chains . Your Base or Polygon dApp can gate on an AIR credential without users bridging anything. zkTLS (web-proof generation) , the sleeper feature. It converts Web2 activity into Web3 credentials : a user can prove facts about data behind a TLS session (a bank balance range, a follower count, a purchase history) without the platform's cooperation and without revealing the session contents. This is how the "portable reputation" thesis escapes the crypto bubble. Decentralized identity storage (the MCSP layer) with user-held keys. Native zkProof verification at ~1-second block times (CometBFT consensus, EVM-compatible via an EVMOS-based architecture). \ Economics: $MOCA is gas, validator stake, and the fee unit for storage, oracle, data generation, and verification ( Animoca Brands ). Issuers can monetize when their credentials are verified elsewhere, Blockworks framed the whole system as a crypto-native alternative to Google SSO where users, not platforms, are the counterparty ( Blockworks ). Testnet (ID 222888) is live; mainnet (ID 2288) transitions through 2026, alongside the consumer-facing MocaProof verification app that beta-launched in December 2025. \ Developer experience: fast login, honest walls Login is a genuine 30-minute integration. Credentials cost you an afternoon, by design: nothing issues or verifies until your JWKS endpoint is live, public over HTTPS, and registered in the dashboard and localhost is unreachable from AIR's servers, so local dev means an ngrok/cloudflared tunnel ( JWKS setup ). It's the right security architecture and the wrong first-hour experience; know it going in. \ Two more field notes. The Developer Dashboard itself is wallet-gated , you connect a wallet to manage credential programs. Coherent with the self-sovereign thesis; friction for the Web2 teams the product courts. And the Sandbox environment defaulted to Moca Chain Testnet at 1.8.0-beta (breaking from Devnet, ID 5151), Devnet credentials don't carry over, so re-issue test credentials on Testnet. \ The parts that impressed me: the Issue-on-Behalf REST API for event-driven backend issuance (KYC webhook fires → credential lands, no user session, poll until vcStatus: ONCHAIN ), the optional Compliance Access Key framework for consent-gated auditor access, a pragmatic bridge between ZK purity and regulated reality. Plug & Play templates claiming sub-30-minute forkable issuer/verifier apps; a turnkey Veriff-powered-by-zkMe KYC pipeline that outputs AIR credentials directly; and an MCP endpoint so AI coding assistants answer from live docs, I pointed Claude at it mid-review and got version-accurate answers. \ The parts that didn't: dashboard-first configuration (schemas, issuance and verification programs are all UI-managed, fine for product teams, painful for infrastructure-as-code shops wanting a Terraform provider that doesn't exist), and Flutter distributed through a private OnePub repository requiring credentials from the team , with Credential Services still absent on mobile ( installation docs ). \ The market: why this category, why now The decentralized identity market is one of the few categories where every research house disagrees on magnitude but agrees on direction. The most conservative credible forecast, Mordor Intelligence, puts it at $7.4B in 2026 growing to $58.74B by 2031, a 51.34% CAGR ( Mordor Intelligence ); Grand View Research runs as high as $102B by 2030 ( GVR ). Structural drivers: repeat-KYC cost, breach liability, GDPR/eIDAS-class regulation and accelerating fastest, AI agents that need verifiable, delegated identity. \ AIR Kit's position post-consolidation is singular: its former peers now optimize for acquirers' strategies (Stripe's payments, Fireblocks' custody, MetaMask's ecosystem), while AIR Kit runs the vertical play, SDK, chain, storage, oracle, one stack, monetized through $MOCA and a credential marketplace. Its deepest moat isn't code; it's Animoca distribution. The honest counterweights: a token-coupled cost base (verifier fee wallets hold $MOCA, so infra cost has a market-price component), and the docs' own warning that Testnet credentials must be re-issued at mainnet , with Issuer/Verifier DIDs possibly changing. Everything you ship today is staging. \ Use cases: where it wins, where it doesn't Drawn from the docs' own decision guide plus my read of the verticals: Use it for: KYC-once ecosystems (fintech, exchanges, telco, issue at onboarding, every partner verifies via proof, PII never re-collected); gaming and loyalty (portable achievements and tiers across titles without bilateral API deals, Animoca's home turf); age/region gating (the cleanest ZK story there is); Web2-reputation import via zkTLS (prove off-chain facts on-chain without platform cooperation); and AI agents (agent keys + verifiable credentials = agents that can prove authorization — early, but the primitives are shipping now). \ Skip it for: flows demanding centralized authority over fast-changing data; ultra-low-latency verification paths where any decentralized round-trip is unacceptable; manual document review outside ZKP-compatible claims, all per the docs' own candor. I'll add: Flutter-first products until Credential Services land on mobile, and anything with a hard compliance deadline before mainnet stabilizes. \ Verdict AIR Kit is the first onboarding SDK I've tested where identity feels like the product rather than the pitch deck. The explainer half of this piece exists because the system deserves to be understood on its own terms: a login that quietly deploys a smart account, credentials that anchor hashes on-chain while plaintext stays with the user, an oracle that lets 25+ chains verify without bridging, and zkTLS that drags Web2 reputation on-chain without asking permission. The review half exists because understanding isn't endorsement and the measured story holds up: category-best footprint, a working ZK loop on testnet, and agent primitives shipping ahead of the narrative. \ What it asks in return is tolerance for pre-mainnet ground shift, a JWKS afternoon, and a bet on $MOCA-denominated economics. New Web3 developers get the gentlest ZK on-ramp I've seen. Veterans get primitives that simply don't exist in the Stripe-ified alternatives. Build on sandbox now; hold production for mainnet GA. \ Don’t forget to like and share the story! :::tip Vested Interest Disclosure: HackerNoon has reviewed the report for quality, but the claims herein belong to the author. #DYOR. ::: \