Minds, Moca AIR and Moca Chain: what builders can use (research, 2026-10-16)

This is desk research from public pages, read on 2026-10-16. No accounts were created for it. Anything not confirmed by a primary source is marked unverified.

#1. Minds (Animoca Brands)

• What it is: a personal, persistent AI-agent platform. Users reach their Mind through Telegram or email. Press coverage dates the launch to February 2026 (The Paypers). The landing page is hellominds.ai.
• Builder Hub: build.hellominds.ai. It has an llms.txt and an agents.json.
  • Concepts: Mind, Soul (identity, memory, continuity), Brain (the model), Skills, Circles (a trust gate: unknown senders are silently blocked) and the Bazaar, where Skills and Apps are listed. See the FAQ and Circles.
  • Builder API key: created in the Builder console and shown once. It is sent as X-Api-Key, or users authenticate with OAuth ("Sign in with Minds", Connect SDK 0.1.2). See account setup and Connect.
  • Client library: @animocabrands/minds-client-lib 0.1.7, Node 22 or later. It covers Minds, equipping skills and apps, Circles, Bazaar, messaging, SSE events and Cognition Credits. See client library.
  • Minds CLI: for driving Minds from coding agents. See CLI.
  • REST API: routes under /v1/, including POST /v1/minds/awaken, PUT /v1/minds/{id}/skills, GET /v1/bazaar/skills, POST /v1/messaging/message and GET /v1/minds/{id}/credits. See the API reference.
• How Skills are built (Skill Building Guide):
  • You describe the Skill to your Mind, and the Mind assembles four parts:
    • a Registry Offering: the Bazaar listing;
    • an App Manifest: how the Skill connects to the app;
    • Tool Schemas: what the Skill can do;
    • a Skill Playbook: how the Skill behaves.
  • For your own tool, you "paste its API docs into the chat".
  • App credentials are stored by the platform as Connections. The Mind never holds the key.
  • You publish by asking the Mind to publish the Skill to the Bazaar.
  • The concrete manifest and schema formats are not published. Whether they use MCP, OpenAPI or a custom format is unverified. This is why Karatum ships an OpenAPI document for the Mind to build from.
• Chain, wallet and on-chain agent identity: no Minds document mentions a chain or wallet (unverified). The only balance in the docs is Cognition Credits.
• GitHub: no public Minds organisation was found (unverified). An n8n community node n8n-nodes-minds exists on npm.
• Minds Investment Programme (programme, apply):
  • up to US$10M in total, offered as cash plus Cognition Credits;
  • for founders building agentic products on Minds now or within weeks, where the product clearly beats a non-agent version;
  • rolling review.
  • Equity, IP and follow-on terms are unverified: the programme FAQ only lists topics.

#2. AIR + Minds with Reap and Pivota (8 Oct 2026)

Source: Animoca Brands announcement.

• Roles in the announced flow:
  • AIR lets users share verified attributes and earned entitlements with Minds agents without exposing the underlying data. It gives cryptographic proof of eligibility and scoped, user-defined agent permissions.
  • Minds reads the user's intent and coordinates the purchase.
  • Reap issues cards and payment credentials scoped to a merchant, amount and time window, applies coupons and runs checkout. It provides stablecoin-based card and payment infrastructure.
  • Pivota is the merchant decision and order-execution layer. It chooses product, merchant and path from live price and availability, and orchestrates the order through the merchant's own stack. The merchant stays merchant of record, and Pivota does not handle the flow of funds.
• Status: a controlled demo with one unnamed merchant. The announcement links no developer docs for Reap or Pivota.
• AIR's Agent API names Pivota directly:
  • The checkout session scope pivota.checkout is "currently the only supported value" (agent OpenAPI, create checkout session).
  • The checkout token's aud is the mapped merchant, and the merchant must verify it.

#3. AIR Kit: what an issuer and verifier can use

Docs: docs.air3.com. docs.moca.network redirects there. There is also a docs MCP server at https://docs.air3.com/mcp and an llms.txt.

• Environments (environments):

  Environment	Chain	Dashboard
  Sandbox	Moca Chain testnet (222888)	developers.sandbox.air3.com/dashboard
  Production	Moca Chain mainnet (2288)	developers.air3.com/dashboard

  SD-JWT credentials are self-serve in production. Iden3 credentials need the AIR team.

• Issuing:

  • A partner JWT (RS256 or ES256, kid = partner id, verified against the partner's JWKS) authenticates the issuer.
  • The issuer backend serves available-vc and issue-vc.
  • The reference issuer is MocaNetwork/air-issuer-service, branch main_sd-jwt-vc, which Karatum runs as a fork.
  • That issuer also has an admin route, POST /admin/issue-vc, which issues server-side to an AIR user. It resolves the user with AIR initialize-user, encrypts the credential to the holder and stores it in AIR DStorage. Revocation is POST /admin/revoke, and the public status is GET /revocation-status/{nonce}.

• Verifying (verify, verify SD-JWT):

  • A verification program is created in the Dashboard. It sets the schema, claim conditions, disclosure and revocation check.
  • Browser and Flutter apps call verifyCredential with the programId and a nonce of at least 128 bits.
  • The docs tell recipients to re-verify the SD-JWT on their own backend, because the wrapper is unsigned.

• Agents (what is AIR Agent, how it works, Agent APIs):

  • Binding: an agent key (air_ag_…) is bound to a user's AIR account with consent and the scopes credentials.read, credentials.verify and commerce.checkout. Partners cannot bind wallet.sign.
  • Sessions and calls: an agent gets a 15-minute agent JWT, then can list the holder's credentials, run POST /v2/credentials/verify-by-agent against a program, and mint a pivota.checkout token.
  • Verification result: Compliant, Non-Compliant or NotFound. A Compliant result carries the SD-JWT presentation, with a key-binding JWT when a nonce is sent and the credential has cnf.jwk.
  • Activation: agent keys must be enabled on the partner account. Otherwise every call returns 403 AGENT_KEYS_DISABLED.
  • Not released yet: "delegation credentials" (per-task authority) and web3 wallet delegation.

• AIR Money:

  • ERC-4337 smart accounts with a paymaster, on Base, BSC, Gnosis, Kaia and Soneium mainnets, and on Base Sepolia and other testnets (supported chains).
  • Moca Chain is not in that list.

• Repositories and packages:

  • GitHub MocaNetwork: air-issuer-service, air-credential-verifier-template, air-credential-example, air-examples, air-agentic-wallet-skill, air-dev-skill.
  • npm: @mocanetwork/airkit 1.12.1 (used by Karatum's /passport claim flow), @mocanetwork/identity-js-sdk 3.0.1 and @mocanetwork/air-ai-services 0.1.0-next.1.

#4. Moca Chain

Sources: network information, mainnet announcement.

• Both networks use the native token $MOCA, have blocks of about 1 second and finalise in one block.
• The testnet faucet needs an AIR account login. Karatum does not log in on anyone's behalf, so funding is an owner action.
• Karatum's checks against the testnet RPC on 2026-10-16 (services/minds moca-cli.ts status):
  • head block about 32.9M;
  • no code at the usual EAS addresses (0xC2679f…815e, OP predeploy 0x4200…0021) or at the ERC-8004 vanity registry;
  • Multicall3 is present.
• EAS or an equivalent attestation registry on Moca Chain: none found, unverified. AIR credentials are anchored through AIR's own credential and revocation layer.
• USDC on Moca testnet: not found, unverified.

#What needs an account, key or contact