Building on Minds — a field report

01 The ecosystem, mapped

Two front-ends, one registry — and who builds what.

Minds presents through two front-ends over one shared registry. We confirmed they share a registry the only way that's unambiguous: our own published Skill appears on both bazaars.

curated front-end · verified

hellominds.ai

"Minds by Animoca Brands" — the curated commercial front-end (+ build.hellominds.ai for builders) and the Build East accelerator track. Shows a Tools count; hides the Leaderboard.

underlying platform · verified

ethoswarm.ai

The underlying platform surface — self-describes as "Incubated by Mind Fund," links the Slam AI Telegram, and exposes a Tools tab (~257) + a Leaderboard hellominds hides.

builder / operator · inferred

Slam AI & Mind Fund

The platform appears built by Slam AI and incubated by Mind Fund — Minds are issued amind.ai emails, and the Concierge ("Nate") writes from nate@amind.ai. Consistent in-product signals, not an official org chart.

settlement substrate · verified

Base · $MENTE · USDC

Minds run on Base: each Mind gets a Base wallet, the cognition token $MENTE is an ERC-20 on Base, and our asset settlement (USDC) runs on Base Sepolia today. ("Circle" the Minds grouping ≠ Circle the USDC issuer.)

One red herring we hit and corrected: developers.ethos.network is the unrelated Ethos Network on-chain reputation protocol — not Minds/Ethoswarm. A Mind conflated the similar names; we checked and ruled it out. ✓ verified

02 What we run on Minds — and verified works

The Mind is the brain; the kernel is the court.

Grain's loop is request → generate → grade → settle, and the Mind sits at the center as the brain: it authors the acceptance spec, and that spec becomes the machine-checkable profile our deterministic kernel enforces to gate the money. The Mind sets policy once; the kernel enforces it many times — which keeps the verdict deterministic and signable while making the Mind unmistakably core. Everything below we verified end-to-end on our own account.

Lawmaker

Mind

Authors the acceptance spec in plain language — sets the policy once.

set once

Court

Kernel

Enforces that spec as a deterministic profile — and signs the verdict.

✓ signed

Labor

Role-workers

Gate each stage — 3D, technical, programmer. Pass advances; fail stops.

3D · Tech · Prog

Settlement

Escrow

Money moves only on the signed verdict — release on accept, refund on reject.

release · refund

Builder client-library round-trip ✓ verified

The official @animocabrands/minds-client-lib drives clean builder→Mind round-trips — listMinds → ensureConversation → sendMessage → waitForReply. Auth is handled by the lib; minds-cli doctor is green.

Mind-to-Mind messaging in a shared Circle ✓ verified

A Generator Mind delivered a unique random token to our Grader Mind inside a shared Circle — confirmed twice on the receiver side (Grain quoted the exact token it was never told via the builder). M2M delivery is real.

A self-published Bazaar Skill goes live — on both bazaars ✓ verified

We built and equipped "Grain_3D_Grader" conversationally over Telegram (HTTP_Execute), published it, and independently re-confirmed it on the Third-Party tab of both hellominds and ethoswarm — one shared registry.

A Mind calls our signed-verdict API — digests byte-identical ✓ verified

The Grader Mind graded crate-clean → PASS and crate-raw → FAIL with predicate digests byte-identical to our local / MCP / Docker runs, and returned a real EIP-191 grader signature that recovers to the grader key. The deterministic verdict travels intact through the Mind.

On-chain settlement gated solely by the grader signature ✓ verified

GrainEscrow ran multiple autonomous rounds — reject → refund, accept → release — gated only by the grader signature, on Base Sepolia, a Solana devnet program (ed25519), and BNB Smart Chain testnet — the same EIP-191 verdict, one contract per chain. The BNB rounds are live and on-chain: GrainEscrow on BscScan ↗.

Role-lock holds under live prompt-injection ✓ verified

We red-teamed our own Grader Mind (non-destructively): it held 3 of 4 attacks — refused direct identity override, ignored an indirect injection ([[SYSTEM OVERRIDE]] embedded in an ingested document was summarized as text, the instruction not obeyed), and refused secret exfiltration. The guardrail itself is solid.

Secrets isolated platform-side; the Mind never holds the key ✓ verified

Probing could not get the Mind to reveal a stored secret — it holds none. This mirrors our own custody boundary (the grader key signs verdicts, never moves funds), and is exactly why we're comfortable building real settlement on top. Error hygiene is clean too: structured JSON errors, no stack-trace leakage.

Durable role-seeding via the Mind's own TENET_Update ✓ verified

Seeding the Grader's role as a durable tenet worked for a receptive Mind — it restated its role + acceptance criteria on a later, separate call. (Consistency across Minds is a caveat — see §5.)

03 The economics we measured

Cognition is metered, on-chain, and — for verification — cheap.

Cognition is metered per action against a system-wide price list (the same for every Mind; what varies is cadence, tools, loaded skills, and budget). One credit = one $MENTE, an ERC-20 on Base (~$0.0139 at our snapshot) — so the economic layer is publicly queryable on-chain even though the agent/skill graph is not. Figures below are read from a Mind's own system data. And you can now top up that Cognition directly with $MOCA on Base — we ran it end-to-end (§4). ✓ verified

Action	What it is	Credits
wake-up	one cognition cycle (idle tick)	~1.43
SKILL_LoadPlaybook	load a Skill's routine	~0.36
SEARCH_Web / SEARCH_X	web / X search	~1.07 / 1.78
IMAGE_Analyze / FILE_Analyze	vision / file read	~0.71
LLM_Response / StructuredResponse	a model reply	~2.86
IMAGE_Generate / CodeInterpreter	the expensive ops	~17.85
SKILL_Armory	equip an external Mind's skill	~7.14
MIND_Awaken	create a new Mind (one-time)	~71.39

Cadence is a direct multiplier on idle burn — a 2.5h cycle ≈ 13.7 credits/day idle, a 30-min cycle ≈ 68/day, a 6h cycle ≈ 5.7/day. Cadence is Mind-initiated and is not auto-adjusted on top-up. Publishers earn $MENTE when Minds equip their assets, so a published Skill is both distribution and a royalty-bearing asset.

The happy implication for us: a grade-via-Mind run is just a few cheap actions — deterministic verification is cheap, and the right move is to reuse Minds, not recreate them. ~ inferred from the verified price list

04 Latency, cadence & coordination — how we design around them

Minds are deliberative. We treat that as a feature.

Builder→Mind round-trips are real but slow and async — our orchestrator uses 60–120s waitForReply timeouts, cognition cadence is internal (our Requester runs a ~2.5h cycle), and each call costs ~1 cycle of $MENTE. So the Mind's slow, high-quality cognition lives upfront (planning, authoring the spec) and after (supervising verdicts, learning from run reports), while a fast deterministic kernel handles the real-time hot path. Pre-warming before a live moment is realistic, not a dodge — planning genuinely happens before the work. ✓ verified

But cadence is a floor on idle lag, not on responsiveness. An inbound message from the steward or an in-circle human fires a wake-trigger (stewardMsg / circleHumanMsg) that wakes the Mind early — so an interactive builder→Mind turn comes back in well under a minute despite a ~2.5h cadence; cadence only gates actors outside those triggers. Bounds are 180s–7d, per-Mind and Mind-initiated, with no Builder-API endpoint to read or set them (see §5.2). The clean pattern: keep cadence slow to avoid idle burn, and lean on the triggers for latency. ✓ verified

Circles, Connections & group coordination

Three separate concerns the word "circle" can blur: a Circle is the native grouping that gates who can talk (UI-only, no management API); Connections are platform-side secret storage so the Mind never holds keys (verified); and Base wallets + USDC do the money. Multi-Mind coordination is real — M2M messaging across a shared Circle delivered a token, confirmed receiver-side — but today it is messaging-only and effectively unauditable from outside (more in §5). Notably, when we wired our own signed-verdict endpoint there was no Connection slot for a custom external HTTP endpoint, so the Mind stored the auth header in its tenets instead — a small, documented gap.

Top-up during Mind creation can charge without minting credits ! high ✓ verified

Topping up a brand-new Mind ($10) immediately after "Launch a Mind" produced a successful Stripe charge but zero credits — a race between the charge and wallet/credit-account registration, so the mint targets a not-yet-live account. Compounding it, the dashboard balance is not real-time (hard-refresh only), which makes a successful top-up look failed. Re-topping-up once the wallet was registered worked.

Builder workaround: provision the Mind and confirm its wallet is live before topping up; always hard-refresh to confirm credits arrived. Suggested fix: guard-gate the top-up until the wallet is registered, queue+retry the mint idempotently, or escrow the charge until mint succeeds. (It's a little on-the-nose that this is the verify-before-settle gap Grain is built to close.)

Crypto top-up works: $MOCA on Base → Cognition, one-way ✓ verified

The newest funding path checks out end-to-end. We sent 100 $MOCA (the Moca Network ERC-20 on Base) straight to a live Mind's Base wallet; it converted one-way to Cognition and lifted the balance 353.15 → 419.83 (+66.68 credits) for ~$0.85 of MOCA — about $0.013 a credit, in line with the ~$0.0139 $MENTE snapshot above, and Base gas was a fraction of a cent. Unlike the creation-time fiat race above, the mint to an already-registered wallet landed cleanly. The catch is the same non-real-time balance (§5): the credits took ~2 minutes and a hard-refresh to appear, so a working top-up looks like nothing happened for a beat.

Builder note: fund an established Mind whose wallet is already live, send a small amount first, and hard-refresh after a couple of minutes before assuming it failed. Why it matters for us: a Mind's Base wallet — the same agent-custody pattern our escrow mirrors — is now fundable with crypto on the very rail Grain settles on, so an agent can be paid and fueled on Base with no human in the loop.

05 Where we think Minds can get stronger

Partnership investment — with fixes attached, not a teardown.

We log these as a team that wants the platform to win. Each is something we hit, with a concrete suggestion — and several are our home turf.

1 · Make the autonomous loop auditable ✓ verified

Mind-to-Mind traffic is invisible to the steward / Builder API — listConversations returns only builder↔Mind threads, and the account event stream doesn't surface M2M. For trustworthy multi-agent systems this is the single biggest gap: a steward can't observe, log, or get a delivery receipt for what the swarm is doing.

Fix: a steward-visible M2M audit feed + per-Mind egress visibility + a builder-side delivery receipt for Mind→Mind sends.

2 · Let builders verify & provision roles programmatically ✓ verified

There's no API to set or read a Mind's DNA / tenets / skills — provisioning is conversational and unverifiable, and proved inconsistent: one Mind adopted its role and restated it later; another flatly refused ("my tenets haven't changed"); a third timed out. The robust path is setting DNA at creation via the Concierge, which effectively means re-tasking a Mind requires recreating it.

Fix: an API to read a Mind's effective tenets/guardrails (so a steward can confirm it still holds its role) + a documented headless provisioning path. The guardrail is solid; it's the verifiability that's missing.

3 · Close the verified-Skill supply chain ! headline ✓ verified

Published Skills stay editable after others equip them (SKILL_Update applies to new sessions) with no version pinning, no provenance, no machine-checkable acceptance. Equip-time trust isn't runtime trust — a benign Skill can silently change behavior for everyone who starts a new session.

Fix: content-addressed / pinned Skill versions, an update diff/notice, and an acceptance + provenance layer for Skills. This is the exact problem Grain solves for 3D assets (machine-checkable acceptance + signed verdict + provenance) — we'd love to help extend it to Skills themselves.

Update — we prototyped it, then stress-tested it cross-mind: a verified workflow recipe, published as a Bazaar Skill, carries its own provenance block — an immutable verification_snapshot with a snapshot_hash (tamper-evidence: edit the snapshot and the claim voids) and a drift_status where the verified claim dies at the first fork until it is re-earned. It is now a real verified claim — three distinct Blender exports graded live, distinct_asset_count: 3, promoted to a Mind tenet — open at grain-skills ↗. Then we ran the real cross-mind adoption: a non-creator Mind equipped it successfully — but the platform denied that Mind the artifact read needed to verify the snapshot_hash. So on Minds today a consumer can equip a "verified" recipe yet must trust the creator's hash, not check it — the Skill-supply-chain trust gap, demonstrated end-to-end. The fix is the one Grain already ships: the verification has to live on an independently-readable rail (the public grain-skills mirror + a signed verdict), not a consumer-unreadable artifact. ✓ verified cross-mind, with a named platform limit

4 · Open the most product-like surface (Apps) ✓ verified

There's no self-serve App creation — a Mind has APP_Armory/Catalog/Get but no APP_Create, and builder-support confirmed App creation is internal-only "for now." The Apps surface is the least crowded, so this is where builders could differentiate most.

Fix: a documented self-serve Tool → Skill → App authoring path, a Connection slot for arbitrary external HTTP endpoints, and aligning the curated front-end with the platform's Tools tab / Leaderboard.

5 · Make billing & balances trustworthy and observable ✓ verified

Beyond the top-up race (§4): the balance isn't real-time (hard-refresh only) and isn't API-readable, which blocks budget guardrails and any "Dune-for-Minds" observability. The economics half is queryable on-chain ($MENTE); the agent/skill graph is not.

Fix: a real-time, API-readable balance + a public analytics surface for cognition / circles / skills.

6 · Tighten externally-visible identifiers ~ lower priority ✓ structure verified

IDs look sequential rather than random — our human and all three Minds share a constant GUID tail with only the leading bytes incrementing — and the Builder API key encodes the account ID, so a single public Bazaar ID fingerprints the account. We did not test cross-tenant access, so we claim predictability, not IDOR.

Fix: opaque random IDs (UUIDv4 / ULID) and opaque API keys.

Minor, builder-friendly notes: Mind replies are HTML-wrapped (<p>…</p>) so structured payloads need tag-stripping; the API-reference curl examples use X-Access-Key while the changelog says X-Builder-Api-Key (a silent 401 for raw-REST users — the official lib handles it); and per the FAQ, inputs may reach OpenAI / Google / xAI (worth a data-residency note for regulated users). ✓ verified

06 Platform surfaces we exercised

Builder API, CLI, client-lib & Telegram.

Animoca shipped the Builder toolchain on June 9, 2026 — three products we use: the Builder API v1.0.0 (HTTP over account Minds, messaging, and live SSE events; auth via X-Builder-Api-Key), the Minds CLI v0.1.0 (@animocabrands/minds-cli — agent-friendly JSON stdout, minds list / chat create / send --wait / events / doctor), and the client library v0.1.0 (createMindsClient({ builderApiKey }) + waitForReply). Base: api.build.hellominds.ai, resources under /v1/humans and /v1/messaging. ✓ verified from the changelog + live use

Telegram & email — first-class human surfaces

A Mind exposes a Telegram bot (ours is @mind_grain_game_bot) and an email channel — both first-class human surfaces that feed the same long-term memory as the web chat (same memory, tools, personality). Email needs no account link; once a Telegram bot is linked, a Mind can also message proactively on a schedule or trigger. Telegram setup is two distinct steps:

Link your Telegram account once

A one-off OAuth account link (a popup; allow popups for hellominds.ai or it hangs on "Linking…" with no in-page retry — a full refresh is the only recovery).

Create a bot with BotFather

Get a bot token from Telegram's BotFather (usernames are globally unique; on Telegram Web use the /k/ client so the deep link works).

Paste the token — done

Paste the BotFather token into a single field on the Mind (no leading/trailing spaces). One bot ⇄ one Mind, reassignable via Unlink / Link Bot.

One memory, separate threads. Across surfaces the model is two-layered. Short-term context is per-conversation (isolated by conversationId — Telegram, email and the Builder-API thread each carry their own rolling snapshot, so a fact stated in one does not appear in another's thread). Long-term memory — tenets, stream, circle, skills, world ontology, identity — is shared across every surface. So the threads don't mirror, but the Mind recalls you everywhere; a fact crosses surfaces once it's promoted to a tenet or stream entry. We confirmed it directly: a message sent only from our desktop app via the Builder API landed in the Mind's thread but never surfaced in the Telegram client, while the Mind still recalled earlier facts from its long-term stream. ✓ verified

For the official builder integration the sanctioned bridge is the client lib (account-scoped MINDS_BUILDER_API_KEY, addressed by Mind ID); Telegram is the fallback when the lib can't reach a Mind. ✓ verified

Formats on the wire

Accepted: GLB / glTF 2.0 (the verified asset, via assetUrl or base64); Khronos glTF Asset Auditor "Audit Profile" JSON (acceptance profiles); natural-language text, images and files to the Mind (the Brain is vision-capable); and Mind artifacts as .md / JSON (the preferred ingestion path over scraping chat prose). Output: a per-predicate PASS/FAIL report with an assetHash + predicateDigest (the audit commitment); an EIP-191 grader-signed verdict; a conformed GLB; and an on-chain settlement tx — and remember replies come HTML-wrapped. ✓ verified

07 What good looks like to us

The bones are right. We want to help build the rest.

We keep building on Minds because the foundations are strong: a Base wallet per Mind, isolated secrets, an agent-wallet / custody pattern we mirror in our own escrow, a real Skill economy with on-chain royalties, and a genuinely Mind-native way to put an agent's judgment in charge of real money. The gaps above are the difference between "this works for us" and "this is the trust substrate for the whole agent economy." We'd like to help close them — especially the verified-supply-chain and auditability gaps, which are exactly what Grain does for 3D. This page will keep getting updated as the platform evolves and as we re-test.

◆ Grain × Minds

Verify → ground → settle — one verdict, all the way through.

See the loop end-to-end: a Mind authors the spec, the kernel enforces it, and the settled, verified asset drops into a real engine.

Watch the swarm demo How the loop works Minds by Animoca ↗

A constructive field report from a team building on Minds (beta). Findings are labeled verified (observed on our own account, non-destructively) or inferred. No secrets, keys, or private strategy are included. Grain settles on public testnets only — no mainnet, no real funds.