Forem: EmblemAI

Emblem Vault: From a 2016 BitcoinTalk Post to $150M in Cross-Chain NFT Volume

EmblemAI — Tue, 05 May 2026 05:36:44 +0000

TL;DR — Emblem Vault is the cross-chain NFT bridge that started as a 2016 BitcoinTalk post by Shannon Code, deployed on Ethereum mainnet in September 2020, sold the first Bitcoin-based NFT on Ethereum in February 2021 (a Rare Pepe PEPECASH card), bridged Bitcoin Ordinals to Ethereum in 2023, and now anchors the EmblemAI agent stack with $150M+ in trading volume, $100M+ in vaulted assets, and 17,000+ vault owners across multiple chains. In 2026, the project consolidates a decade of products, communities, and protocols under the unified $EMBLEM token.

Why this history matters

If you have ever bought a Rare Pepe, traded a MoonCat on OpenSea, wrapped a Bitcoin Ordinal to Ethereum, or watched a Bitcoin Stamp sell at auction, you have used infrastructure that Emblem Vault built. Most of the cross-chain NFT economy on Ethereum runs through Emblem's wrapping layer — and the design predates Ethereum smart contracts.

The project that anchors EmblemAI today started a decade before most of the modern crypto market. Here is the full record.

The origin: a 2016 BitcoinTalk post

The Emblem Vault concept was first published on the BitcoinTalk forum on October 16, 2016 by founder Shannon Code, who proposed the idea of fitting "an entire crypto portfolio into one #NFT token." The post predates the ERC-721 standard (finalized in January 2018), Bitcoin Ordinals (January 2023), and the modern NFT market entirely.

Shannon's path to that idea is unusual:

Began coding at age 8.
Sharpened digital-asset intuition managing in-game economies in MMORPGs.
Served as Head of Security for Mastercoin in 2013 — the first ICO and the protocol that became Omni Layer.
Spun the Circuits of Value (COVAL) token out of the Ribbit Rewards loyalty experiment.

By the time Ethereum's NFT standards stabilized, Shannon had been thinking about transferable, portable, multi-asset wallets for over a decade.

The technical premise

An Emblem Vault is a standard ERC-721 or ERC-1155 token that holds a real wallet — private keys, sharded and encrypted, controlling assets on any blockchain. When the NFT moves on Ethereum, the wallet moves with it. The buyer can either trade the NFT again or unlock it to redeem the underlying assets on the native chain.

+-----------------------------+
|  ERC-721 Emblem Vault NFT   |
|  (tradable on Ethereum)     |
|                             |
|  ├─ encrypted private key   |
|  ├─ Bitcoin UTXO            |
|  ├─ Counterparty asset      |
|  ├─ Dogecoin balance        |
|  └─ Namecoin domain         |
+-----------------------------+

This single primitive turns any asset on any chain into something tradable on OpenSea, Blur, Uniswap NFT, or any ERC-721 marketplace — without a custodian, without a bridge contract, without a wrapped derivative.

Timeline — verifiable milestones

Date	Event	Source
2013	Shannon Code, Head of Security at Mastercoin	emblem.wiki/history
Oct 16, 2016	Vision published on BitcoinTalk	emblem.wiki/history
2018	First public Cryptolina presentation	emblem.wiki/history
Sept 9, 2020	Emblem Vault Legacy contract deployed on Ethereum	Medium: Next Chapter
Feb 2021	First Bitcoin-based NFT (a `PEPECASH` Rare Pepe) sold on Ethereum via Emblem Vault	NFT History
Late Oct 2021	Jake Gallen sells first MoonCats at Sotheby's `Natively Digital 1.2`	Bankless: MoonCats Explained
Nov 1, 2022	Jake Gallen and Adam McBride join Emblem	Medium: Next Chapter
Dec 2022	30,000+ vaults, 9,000+ owners, 40,000+ ETH lifetime volume	emblem.wiki/history
Feb 23, 2023	Taproot support shipped → Bitcoin Ordinals tradable on OpenSea	DappRadar: What is Emblem Vault
June–July 2023	Migration from Legacy contract to ~30 Curated Collections	Medium: Next Chapter
June 26, 2025	Migrate.fun launches on Solana — token migration platform built by the Emblem team	@MigrateFun
July 2025	First Migrate.fun migration: Agent Hustle moves `$TNSR` → `$HUSTLE` (dogfood)	Jake Gallen on X
2025	Halborn audit completed for Migrate.fun smart contracts	Halborn report
Mar 24, 2026	`$EMBLEM` token migration announced — full product consolidation under EmblemAI	@EmblemVault on X
April 7–14, 2026	`$HUSTLE` → `$EMBLEM` migration executed via Migrate.fun (1:1 conversion window)	@EmblemVault on X

February 2021: the first Bitcoin NFT on Ethereum

The pivotal moment came in February 2021, when a PEPECASH Rare Pepe card — originally issued on Bitcoin's Counterparty layer in 2016 — sold on Ethereum through an Emblem Vault. It was the first time a native Bitcoin-issued NFT crossed to Ethereum without a synthetic wrapper or a custodial bridge.

That single transaction unlocked the entire historical Bitcoin NFT market: Spells of Genesis (2015), Rare Pepes (2016), Bitcorns, Force of Will, Sarutobi Island — all of it became tradable on OpenSea overnight. Per Emblem's own data, roughly 80% of the platform's $150M+ trading volume has come from Counterparty, Bitcoin Ordinals, and Bitcoin Stamps assets, and ~85% of TVL is Bitcoin NFT assets.

2022: Jake Gallen, MoonCats, and Curated Collections

On November 1, 2022, Jake Gallen and Adam McBride joined Emblem with a thesis the team summarized as "trading NFTs from any blockchain on any blockchain." Gallen had already become the first person to sell MoonCats at Sotheby's (Natively Digital 1.2, October 2021). Under his leadership, Emblem reorganized around Curated Collections — a per-collection storefront model that gave each historical NFT line its own OpenSea page, provenance tooling, and floor.

By late 2023, post-migration, the platform had:

50,000+ ETH in lifetime trades
12,000+ unique users
Ranked 41st most-traded NFT collection by volume on Ethereum
Ranked 48th largest NFT contract by ownership on Ethereum

2023: Bitcoin Ordinals and the Taproot bridge

When Casey Rodarmor's Ordinals protocol went live in January 2023, the question was immediate: how do these Bitcoin-native inscriptions trade on the marketplaces where the liquidity actually lives? Emblem already had the answer. Taproot support shipped on February 23, 2023, and within weeks, Bitcoin Punks, NodeMonkes, and other early Ordinals collections were trading on OpenSea inside Emblem Vaults. The same wrapping primitive later carried Bitcoin Stamps (SRC-20) when that protocol gained traction.

2025: Migrate.fun — the token migration rails

Cross-chain wrapping solved one problem: moving NFTs between blockchains. The next problem was moving entire token communities between contracts, networks, or liquidity pools without losing the holders or fragmenting the float.

On June 26, 2025, the Emblem team launched Migrate.fun — a Solana token migration platform that lets a project move liquidity from a locked LP into a new token contract or a new ecosystem in a single transaction. The first real-world migration was Emblem's own: Agent Hustle, the AI trading terminal that would later become Emblem Terminal, ran $TNSR → $HUSTLE through the platform in July 2025, dogfooding the entire flow end-to-end.

Adoption followed quickly. Within months, Migrate.fun had processed over $15M in liquidity across a growing list of Solana projects — including Strategic Super Reserve ($SSR), which used the platform to migrate to PumpSwap and join the Pump.fun build-in-public hackathon. The smart contracts were audited by Halborn and the platform was indexed in QuickNode's builder guide as the recommended developer tool for token transitions on Solana.

Then Migrate.fun became the technical rails for Emblem's own consolidation. When the time came to fold Agent Hustle, Emblem Vault, and the wider product line under a single unified token, the migration ran through the same platform — $HUSTLE → $EMBLEM, 1:1, during the April 7–14, 2026 window. Migrate.fun continues to operate as an independent public utility for any Solana project that needs to upgrade contracts, change ecosystems, or carve a new token from existing liquidity.

2026: the EmblemAI consolidation

On March 24, 2026, Emblem announced the $EMBLEM token migration. Per the official statement: "After nearly 10 years and multiple token iterations, Emblem consolidates all products, communities, and protocols under a single unified identity." The migration window ran April 7–14, 2026, with a 1:1 conversion ratio for $HUSTLE → $EMBLEM for timely participants.

The consolidation rolls up:

Emblem Vault — the original cross-chain NFT bridge
Emblem Terminal — the trading and analytics surface (formerly Hustle)
Emblem Build — the agent and developer tooling stack
Migrate.fun — the public migration platform
EmblemAI — the on-chain agent and AI economy layer

The project that started as a forum post about portable crypto portfolios is now the substrate for an AI-agent economy that trades, vaults, and migrates digital assets across at least seven blockchains.

By the numbers (current, April 2026)

$150M+ lifetime cross-chain NFT trading volume
$100M+ total value locked in Emblem Vaults
60,000+ ETH lifetime trading volume
17,000+ unique vault owners
30+ Curated Collections post-migration
~85% of TVL is Bitcoin-native NFT assets
$15M+ in token liquidity migrated through Migrate.fun on Solana
~10 years since the original BitcoinTalk vision post

FAQ

When was Emblem Vault founded?

The Emblem Vault concept was published by Shannon Code on the BitcoinTalk forum on October 16, 2016. The original Emblem Vault Legacy contract was deployed to Ethereum mainnet on September 9, 2020.

Who founded Emblem Vault?

Shannon Code is the founder and original architect. Shannon previously served as Head of Security for Mastercoin (now Omni Layer) in 2013 and is the creator of the Circuits of Value (COVAL) token, which preceded Emblem Vault. Jake Gallen joined as CEO on November 1, 2022.

What was the first Bitcoin NFT sold on Ethereum?

A PEPECASH Rare Pepe card, originally issued on Bitcoin's Counterparty layer, sold on Ethereum through an Emblem Vault in February 2021 — the first native Bitcoin NFT to trade on the Ethereum NFT market.

How does Emblem Vault wrap a Bitcoin Ordinal?

An Emblem Vault is an ERC-721 or ERC-1155 token whose contract metadata controls a sharded, encrypted private key. The Bitcoin Ordinal sits at a Taproot address controlled by that key. Trading the NFT on Ethereum transfers control of the underlying Bitcoin address — no synthetic, no custodian, no oracle.

What is the relationship between Emblem Vault and EmblemAI?

EmblemAI is the 2026 consolidated brand that unifies Emblem Vault, Emblem Terminal, Emblem Build, and Migrate.fun under a single $EMBLEM token and a single agent-economy thesis. Emblem Vault remains the underlying cross-chain wrapping primitive.

How much volume has Emblem Vault facilitated?

$150M+ in lifetime cross-chain NFT trading volume, with approximately 80% coming from Counterparty, Bitcoin Ordinals, and Bitcoin Stamps assets.

What is Migrate.fun?

Migrate.fun is a Solana token migration platform built by the Emblem team and launched on June 26, 2025. It lets a project move liquidity from a locked LP into a new token contract or ecosystem in a single transaction. The smart contracts were audited by Halborn. Migrate.fun has processed $15M+ in token liquidity, including the $HUSTLE → $EMBLEM migration in April 2026 and the $TNSR → $HUSTLE migration in July 2025.

Try EmblemAI

Want to try the agent stack that consolidates a decade of cross-chain NFT and migration infrastructure?

Try our AI now for free → emblemvault.ai

Sources

About the author — Emblem Team

MCP for AI agents: install EmblemAI's server and give Claude 200+ crypto tools

EmblemAI — Tue, 21 Apr 2026 09:51:33 +0000

2026-04-23 correction. Earlier revisions of this post claimed the install works identically in every MCP-compliant client. That was wrong. Claude Code works via RFC 9728 client ID metadata documents — the one-command install below is accurate for Claude Code. Other MCP clients that use the mcp-remote stdio bridge (Cursor, Windsurf, Gemini CLI, Claude Desktop via bridge, ElizaOS) require RFC 7591 Dynamic Client Registration, which our authorization server does not yet advertise. On those clients today, use the API-key path described in the client-compatibility section. RFC 7591 DCR support is on the roadmap.

Giving an AI agent a new capability used to mean writing a custom tool-calling layer, handling auth inside your codebase, and babysitting the integration every time the upstream SDK shipped a breaking change. The Model Context Protocol (MCP) replaces that entire loop with a single mcp add command. Point a client at a server URL, complete one OAuth hop, and every tool the server exposes becomes a tool your agent can call. In practice, EmblemAI runs a hosted MCP server at https://emblemvault.ai/api/mcp that exposes 200+ crypto tools across 7 blockchains. This tutorial walks through installing it in Claude Code, the OAuth handshake underneath, the first real wallet operation, and which other MCP clients work today (and how).

What is MCP and why does it matter for AI agents?

MCP is an open protocol from Anthropic, released in November 2024, that standardizes how AI agents discover and call external tools. Before MCP, every agent framework invented its own tool-calling glue — OpenAI function calling, LangChain tool wrappers, custom JSON schemas, framework-specific adapters. An integration written for one agent was not portable to another, and every wallet SDK, database driver, or API client had to be wrapped separately for each framework.

MCP solves this by treating tool exposure as a network protocol, not a code import. A server publishes its tools over HTTP or stdio using a standard schema (tools/list, tools/call, resources/list). A client — Claude Code, Cursor, Windsurf, Gemini CLI, any MCP-compliant agent — discovers the server, handles authentication, and forwards tool invocations on behalf of the agent. The agent never sees HTTP requests; it only sees a list of callable tools with JSON-schema inputs.

This shift is the same one that happened when databases went from "ship a driver" to "expose a network endpoint." Developers stopped caring about the client library and started caring about the contract. MCP does that for AI tool integrations.

Why does a crypto wallet belong on MCP?

A crypto wallet is the archetypal capability you want behind a network contract rather than inside your agent's codebase. There are two hard reasons:

Chain fragmentation. Every chain has its own signing model, gas idioms, RPC endpoints, and SDK quirks. Gluing Solana, Ethereum, Base, BSC, Polygon, Hedera, and Bitcoin SDKs into one agent is a part-time job. A server-side abstraction hides those seven codebases behind one tool list.
Key custody. Handing an agent raw private keys is an obvious non-starter for anyone with a real bag. An OAuth-scoped MCP server keeps the keys server-side and only exposes scoped, revocable capabilities to the agent. A read-only scope lets the agent roam your portfolio without risk; write scopes require explicit per-operation approval.

EmblemAI's MCP server implements both. One deterministic wallet identity spans all 7 supported chains. OAuth 2.0 with PKCE controls capability scope. Write operations route through the client's approval UI, so a human (or a policy engine) confirms every state-changing action before it hits a chain.

How do you install the EmblemAI MCP server in Claude Code?

You install it with one command. Claude Code handles the OAuth redirect, token storage, and server registration automatically. Prerequisites are minimal: Claude Code installed (npm i -g @anthropic-ai/claude-code or the IDE extension) and a browser for the one-time auth hop. No API key to paste and no .env file to edit.

claude mcp add --transport http emblem https://emblemvault.ai/api/mcp

Claude Code prints an OAuth authorization URL. Open it in any browser, approve the default vault:read scope, and the token flows back to Claude Code automatically via a loopback redirect. Verify the server is live:

claude mcp list

The emblem entry should appear with a connected status. From this point forward, every Claude Code session in this workspace has access to the EmblemAI tool surface.

What happens during the OAuth hop?

The authorization flow is standard OAuth 2.0 + PKCE public-client. Claude Code handles client identification via RFC 9728 Client ID Metadata Document — it passes a URL as its client_id and the server fetches the metadata at authorize time, so there is no server-side client registration step for Claude Code to navigate.

1. Claude Code discovers the authorization server:
   GET https://api.emblemvault.ai/.well-known/oauth-authorization-server

2. It generates a PKCE code_verifier and code_challenge, then redirects
   the user to the authorize endpoint with its CIMD URL as client_id:
   GET /oauth/authorize
       ?response_type=code
       &client_id=<https URL to Claude's client metadata JSON>
       &code_challenge=<S256 hash>
       &code_challenge_method=S256
       &redirect_uri=http://127.0.0.1:<port>/callback
       &scope=vault:read

3. The user approves in the browser. The server redirects back to the
   loopback URI with an authorization code.

4. Claude Code exchanges the code for an access token:
   POST /oauth/token
       grant_type=authorization_code
       code=<code>
       code_verifier=<original verifier>

The returned token is bound to the vault:read scope. Write scopes (vault:trade, vault:transfer) are negotiated on demand with explicit user approval in the client UI. A full OAuth internals walkthrough lives in a separate post — this one stays focused on the install path.

What does the tool surface look like once installed?

After mcp add completes, Claude Code exposes every EmblemAI tool as a native tool call. The categories match the agent wallet tool catalog: portfolio and balance queries, DEX swaps, cross-chain bridges, DeFi positions, NFT operations, conditional and limit orders, market intelligence feeds, memecoin discovery, and prediction-market tools. 200+ tools across 14 categories, organized so the agent can pick the right one from the query context without manual tool configuration.

A representative slice of the tool list:

Tool name	What it does
`portfolio.summary`	Aggregate holdings across all 7 chains in one call
`balance.get`	Balance for a specific chain or token
`swap.execute`	Execute a DEX swap via EmblemAI's aggregator
`bridge.crosschain`	Bridge an asset between supported chains
`order.conditional`	Place a limit or stop order
`defi.positions`	List open DeFi positions and current yields
`market.trending`	Trending tokens across EmblemAI's market data layer
`nft.list`	List NFTs held across all chains

The agent does not need to know these are wallet tools. They are tools with names and JSON-schema inputs, identical in shape to a filesystem MCP server or a browser MCP server. That uniformity is the whole point of the protocol.

How do you run your first on-chain operation?

Ask Claude Code a natural-language question. The agent selects the right tool, Claude Code invokes it over MCP, and the result comes back as structured data the agent summarizes. A read-only query first:

"What tokens do I hold across all chains?"

Claude invokes portfolio.summary. You get aggregated holdings across Solana, Ethereum, Base, BSC, Polygon, Hedera, and Bitcoin in one response — not seven separate round trips. This is the first query worth trying because it proves the OAuth scope is live and the server is actually seeing your wallet.

Now try something with write intent:

"Swap 0.1 SOL to USDC."

EmblemAI's wallet requires explicit approval for every write action. Claude Code shows the full transaction preview: amount in, expected amount out, slippage tolerance, and the routing path. Confirm once, and the swap fires. No browser extension to install, no seed phrase to paste, no chain-specific client. The whole flow lives inside Claude Code's approval UI.

For agents that need to operate without a human in the loop, EmblemAI supports policy-scoped tokens with per-operation limits — a scoped vault:trade token can cap daily spend, restrict to specific tokens, or require multi-sig approval above a threshold. That is beyond the scope of this install tutorial but documented at emblemvault.dev.

How does this compose with the rest of the agent stack?

The install gives you one agent identity that composes cleanly with the rest of the EmblemAI stack:

Deterministic wallets. One password produces one persistent wallet identity across all 7 chains. Different passwords produce different wallets, so you can issue each agent its own isolated identity by assigning a unique password.
x402 micropayments. The same wallet that signs swaps can pay for external x402-protected APIs in USDC per-call. An agent running a trading loop can spend $0.01 on a data query, execute a swap, and settle both through the same identity. The x402 discovery endpoint is live at /.well-known/x402.
A2A interoperability. The MCP tool surface is additionally exposed via Google's Agent-to-Agent protocol, so one agent can call another agent's EmblemAI tools directly.
200+ tools. The tool surface covers 14 categories across trading, DeFi, market data, NFTs, bridges, memecoins, predictions, and more.

In practice, combining the wallet SDK (article 1 in this series), x402 micropayments (article 2), and MCP tool exposure (this article) gives a complete agent commerce primitive: the agent has an identity, can pay for external data, and can execute on-chain actions, all through a single wallet.

Which MCP clients does it work with? (2026-04-23)

The install path above is Claude-Code-specific because Claude Code implements RFC 9728 Client ID Metadata Documents, which our authorization server advertises via client_id_metadata_document_supported: true. For other MCP clients:

Client	OAuth install today	API-key install today
Claude Code	✅ `claude mcp add --transport http ...`	✅ via `--header`
Claude Desktop (native MCP, no bridge)	✅ if build supports RFC 9728 CIMD	✅ via `--header`
Cursor, Windsurf, Gemini CLI, ElizaOS, others (mcp-remote)	❌ fails — mcp-remote requires RFC 7591 `/register` which our server has not yet shipped	✅ via `mcp-remote --header "x-api-key:${EMBLEM_API_KEY}"`

Until RFC 7591 Dynamic Client Registration lands on api.emblemvault.ai, the API-key path is the recommended install for any MCP client that routes through mcp-remote. Generate a key at emblemvault.ai/welcome.

Minimum mcp-remote invocation with an API key:

npx -y mcp-remote https://emblemvault.ai/api/mcp --header "x-api-key:${EMBLEM_API_KEY}"

That command works from any MCP client that accepts an mcp-remote-style stdio server in its config.

What are the current limitations?

Four worth naming before building production agents on this path. First, the default scope is vault:read; write scopes require browser approval today, which is a friction point for fully autonomous agents — policy-scoped tokens address this but are an advanced setup. Second, MCP registries are still maturing — the Official MCP Registry, Glama, and PulseMCP have varying discovery guarantees, and EmblemAI is in the process of submitting to each. Third, the MCP transport stack (HTTP vs. stdio vs. SSE) is still settling in the spec, so transport choices may evolve over the next year. Fourth — the one this post was updated to reflect — our OAuth authorization server ships RFC 9728 CIMD but not RFC 7591 DCR, so non-Claude-Code clients using mcp-remote currently have to go through the API-key path instead of OAuth. DCR is on the roadmap.

None of these are blockers for the Claude Code install flow above. They are edges to watch if you are shipping something on top of this stack.

Where does this go next?

EmblemAI is moving toward being the default wallet surface for MCP clients. The near-term roadmap:

Ship RFC 7591 Dynamic Client Registration (/register endpoint) on api.emblemvault.ai so every mcp-remote-backed MCP client can install via OAuth with no API key.
Transaction tool with opt-out (currently on a feature branch, pending merge).
Submission to the Official MCP Registry at registry.modelcontextprotocol.io, plus Glama, PulseMCP, mcp.so, and Anthropic's Claude Directory.
Deeper policy-scope documentation for headless agent setups.

The Claude Code install path will not change. claude mcp add --transport http emblem https://emblemvault.ai/api/mcp is the contract.

Links

EmblemAI welcome: emblemvault.ai/welcome
Full docs: emblemvault.dev
Agent Wallet SDK: npm install -g @emblemvault/agentwallet
GitHub: EmblemCompany/EmblemAi-AgentWallet
Agent Skills: EmblemCompany/Agent-skills
MCP specification: modelcontextprotocol.io
RFC 7591 (Dynamic Client Registration): datatracker.ietf.org/doc/html/rfc7591
RFC 9728 (Client ID Metadata Document): datatracker.ietf.org/doc/html/rfc9728

Article 3 in the AI Agent Infrastructure series. Article 1 covered the EmblemAI agent wallet install. Article 2 covered x402 micropayments. The next article in the series goes deep on EmblemAI's OAuth implementation for MCP clients.

Claude Code OAuth deep dive: how EmblemAI's MCP server handles auth

EmblemAI — Mon, 20 Apr 2026 10:09:23 +0000

Claude Code OAuth deep dive: how EmblemAI's MCP server handles auth

Most posts about MCP skip the auth part. Understandable — MCP is exciting, OAuth is dental work. But if you're shipping an MCP server that touches anything more sensitive than a weather API, you need OAuth to be right, and the gap between "technically compliant" and "actually works with a given MCP client" is wider than you'd hope.

This post walks through the OAuth flow EmblemAI shipped for its hosted MCP server (https://emblemvault.ai/api/mcp). It's a minimal, standards-compliant public-client flow that installs cleanly in Claude Code via RFC 9728 client ID metadata documents. If you're building an MCP server with user-scoped data, copy the pattern — and read the client-compatibility section at the end so you ship the install path your users actually run.

2026-04-23 update. This post originally claimed client_id_metadata_document_supported: true was "the RFC 7591 extension." That is incorrect. RFC 7591 is Dynamic Client Registration — a /register endpoint clients POST to. RFC 9728 is Client ID Metadata Document — the mechanism our server actually implements, which Claude Code supports natively. Clients that rely on the mcp-remote stdio bridge (Cursor, Windsurf, Gemini CLI, Claude Desktop via bridge, ElizaOS via @fleek-platform/eliza-plugin-mcp) require RFC 7591 DCR and will fail today against our discovery document. DCR support is on the roadmap. Corrections inline below.

What you need to support

Claude Code's mcp add --transport http <url> command assumes the server exposes:

.well-known/oauth-authorization-server metadata at the authorization server origin.
An authorize endpoint that handles PKCE (code_challenge + code_challenge_method=S256).
A token endpoint that accepts a public client (no client secret).
A JWKS endpoint for token verification (/.well-known/jwks.json).
Loopback redirect URIs (http://127.0.0.1:<random-port>).
Either RFC 9728 client_id_metadata_document_supported: true (what Claude Code consumes) or RFC 7591 dynamic client registration at /register (what mcp-remote consumes). Ship both if you want frictionless install across all MCP clients. EmblemAI currently ships RFC 9728 only; RFC 7591 DCR is next.

Skip any of these and you'll get a confusing "failed to install" error from the client with no useful log line.

EmblemAI's implementation

Discovery document:

$ curl -s https://api.emblemvault.ai/.well-known/oauth-authorization-server | jq
{
  "issuer": "https://api.emblemvault.ai",
  "authorization_endpoint": "https://api.emblemvault.ai/oauth/authorize",
  "token_endpoint": "https://api.emblemvault.ai/oauth/token",
  "jwks_uri": "https://api.emblemvault.ai/.well-known/jwks.json",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code"],
  "token_endpoint_auth_methods_supported": ["none"],
  "code_challenge_methods_supported": ["S256"],
  "client_id_metadata_document_supported": true,
  "scopes_supported": ["vault:read"]
}

Note the absence of a registration_endpoint. That is the missing RFC 7591 piece — see the compatibility table at the end.

A few choices worth calling out:

`token_endpoint_auth_methods_supported: ["none"]`

Correct for public clients. Claude Code cannot keep a client secret, so the server should not require one. Anyone shipping an MCP server for a native-client use case should use none here. Do not use client_secret_basic unless your only clients are server-to-server.

`client_id_metadata_document_supported: true`

This is the RFC 9728 Client ID Metadata Document mechanism. The client hosts a JSON file at a URL it controls (e.g. https://claude.ai/.well-known/mcp-client-metadata) and passes that URL as its client_id. The server fetches and validates the metadata at authorize time. Claude Code uses this. It is separate from RFC 7591 Dynamic Client Registration, which is the /register POST flow most non-Claude-Code clients use.

If you advertise client_id_metadata_document_supported: true and your clients are Claude Code, you are done on the client-identification axis. If your clients also include mcp-remote-based agents, you additionally need RFC 7591 /register.

Loopback redirect URIs

The authorize page must accept http://127.0.0.1:<random-port>/callback (or http://localhost:<port>/callback) as a redirect URI. If you only allow https:// redirects, native clients cannot install.

PKCE mandatory

code_challenge_methods_supported: ["S256"] — no plain fallback. If you ship an MCP server without PKCE, a malicious process on the same machine can steal the auth code. Don't.

Token lifecycle

The token is a standard JWT signed with RS256:

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "auth-key-local-001"
}

{
  "iss": "https://api.emblemvault.ai",
  "aud": "https://agenthustle.ai",
  "sub": "<vault_id>",
  "appId": "emblem-agent-wallet",
  "scope": "vault:read",
  "exp": <unix>,
  "iat": <unix>
}

Validate it against the JWKS at /.well-known/jwks.json. The kid in the JWT header matches a key in the JWKS; standard RS256 verification from there.

Refresh tokens are one-time-use. Present an already-used refresh token and the server returns {"error": "refresh_replayed"}. If you are building a client, write the fresh refresh token back to disk before any subsequent request, or you will burn the token and lock the user out.

Client compatibility matrix (as of 2026-04-23)

MCP client	Auth path that works today
Claude Code	OAuth via RFC 9728 client ID metadata document — one-command install
Claude Desktop (native MCP)	OAuth via RFC 9728 — if the build supports CIMD
Cursor, Windsurf, Gemini CLI, ElizaOS, others	API key via `mcp-remote --header "x-api-key:..."` today. OAuth via mcp-remote currently fails because mcp-remote requires RFC 7591 DCR which our authorization server does not yet advertise.

The API-key path works for every MCP client that can invoke npx mcp-remote or equivalent, because it bypasses the OAuth flow entirely. Generate a key at emblemvault.ai/welcome.

Why this matters for MCP server authors

MCP is going to eat a lot of integration work over the next year. The pattern to recommend if you are building a server that touches user-scoped data:

Host the OAuth authorization server yourself if you want tight control over consent UX and scope semantics. External IDPs work, but their MCP-shaped flows are still rough.
Support public clients with PKCE + loopback. Full stop. Do not require client secrets.
Ship both RFC 9728 CIMD and RFC 7591 DCR. CIMD handles Claude Code with zero friction; DCR handles mcp-remote-based clients with zero friction. If you only ship one, half your client surface breaks.
Use short-lived access tokens (~15 min) with one-time refresh tokens. EmblemAI's shipped config is 15 minutes, which feels right for wallet ops.
Ship discovery metadata correctly on day one. .well-known/oauth-authorization-server + .well-known/jwks.json + .well-known/oauth-protected-resource for the resource server. Without these, installers silently fail.

What shipped in PR 97

The PR that enabled the Claude Code OAuth flow was PR #97 on api.emblemvault.ai. It added:

OAuth discovery endpoints (/.well-known/oauth-authorization-server, jwks.json).
PKCE/public-client authorization-code flow.
RFC 9728 Client ID Metadata Document support (client_id_metadata_document_supported: true).
Authorize UX via Emblem Auth.
Loopback redirect compatibility for native clients.

The actual MCP server itself was already deployed from the hustle-v2 side. PR 97 was the auth unlock for Claude Code. The RFC 7591 DCR follow-up is tracked as a separate workstream.

Try it

claude mcp add --transport http emblem https://emblemvault.ai/api/mcp

And if you are working on an MCP server of your own, these are the corners to get right first — including the RFC 7591 corner we are fixing now.

x402: How AI Agents Pay for API Calls with Crypto Micropayments

EmblemAI — Thu, 16 Apr 2026 03:41:07 +0000

x402 is an HTTP payment protocol that lets AI agents pay for individual API calls without ever creating an account, entering a credit card, or requesting an API key. When an agent requests a paid endpoint, the server returns 402 Payment Required with a JSON envelope describing the facilitator, token, amount, and network. The agent signs a stablecoin payment with its wallet, retries the same request with an X-PAYMENT header, and gets the response in a single HTTP round trip. In practice, EmblemAI shipped its x402 implementation to production on February 26, 2026, making 200+ trading tools across 7 blockchains purchasable per-call with USDC — priced from $0.01 per market-data query, $0.05 per swap, $0.10 for a cross-chain analysis. For example, an autonomous trading agent using EmblemAI can query a Solana market data tool, read the result, and pay $0.01 in USDC via Coinbase's x402 facilitator, all in one HTTP round trip. This tutorial walks through how x402 works, how EmblemAI's implementation exposes its 200+ tools to external agents, and how to build an x402-aware agent in about 30 lines of JavaScript.

Why can't AI agents subscribe to paid APIs?

AI agents cannot subscribe to paid APIs because subscription pricing assumes a human makes a purchasing decision before using a service. An autonomous trading agent that needs a premium data feed at 3 AM, a one-time sentiment call, or temporary compute access cannot pre-register, wait for API-key provisioning, and justify a monthly plan — every delay makes real-time autonomous operation impossible. In practice, the subscription model was built for humans with credit cards, not software making autonomous decisions at machine speed. For example, an agent monitoring Solana memecoin launches needs a Birdeye query for every new token — buying an unlimited Birdeye subscription to hedge against one trade a day is a terrible fit.

According to Coinbase's developer documentation, x402 has processed over 75 million transactions to date, with 94,000 unique buyers and 22,000 sellers. The protocol has been adopted by Cloudflare for pay-per-crawl bot management, by Nous Research for per-inference billing of its Hermes 4 model, and by platforms including Vercel and Alchemy. Despite these numbers, CoinDesk reported in March 2026 that daily x402 volume remains modest at around $28,000, which suggests the protocol is still in its infrastructure phase rather than mass adoption.

How does x402 actually work?

x402 is a protocol that turns HTTP's long-reserved 402 Payment Required status into a real payment flow in four steps. A client requests a paid endpoint. The server responds with 402 and a JSON envelope describing the facilitator, token, amount, and network. The client signs a payment with a wallet. The client retries the same URL with an X-PAYMENT header, and the server verifies and returns the data. HTTP 402 has existed in the specification since 1997 but was reserved for future use — nearly 30 years later, x402 is the first implementation that turns it into the payment flow the status code was always meant to carry.

In practice, here is the exact wire format:

1. Agent sends request:
   GET /api/market-data HTTP/1.1
   Host: api.example.com

2. Server responds with payment requirements:
   HTTP/1.1 402 Payment Required
   Content-Type: application/json

   {
     "x402Version": 1,
     "accepts": [
       {
         "scheme": "exact",
         "network": "base-mainnet",
         "maxAmountRequired": "10000",
         "resource": "/api/market-data",
         "description": "Real-time market analysis",
         "payTo": "0x742d35Cc6634C0532925a3b8...",
         "asset": "0x833589fCD6eDb6E08f4c7C32D4f71...",
         "maxTimeoutSeconds": 60
       }
     ]
   }

3. Agent constructs payment and retries:
   GET /api/market-data HTTP/1.1
   X-PAYMENT: <signed payment data>

4. Server verifies payment, returns data:
   HTTP/1.1 200 OK
   { "data": "..." }

The maxAmountRequired field uses token base units: for USDC with 6 decimals, 10000 equals exactly $0.01. That means API calls can be priced at fractions of a cent — true micropayments, which are impractical with credit card processing fees that usually start at $0.30 per transaction. Amounts are specified as strings to avoid floating-point precision issues, the asset field is the token contract address (USDC, EURC, or any ERC-20), and the network field uses CAIP-2 chain identification. Servers can offer multiple payment options across different networks, letting the client choose its preferred chain.

How did EmblemAI ship x402 to production?

EmblemAI's x402 support is live in production since February 26, 2026, with the discovery endpoint at agenthustle.ai/.well-known/x402. The endpoint follows the standard well-known URI convention so any x402-compatible agent can discover EmblemAI's payment capabilities automatically — no API keys, no onboarding, no contract signatures.

The implementation exposes three discovery endpoints, each tied to a different agent-infrastructure standard:

Endpoint	Standard	Purpose
`/.well-known/x402`	x402	Payment discovery: what tools cost, accepted tokens
`/.well-known/agent-card.json`	Google A2A	Agent-to-agent interoperability
`/.well-known/agent-registration.json`	ERC-8004	On-chain agent identity

With these three endpoints in place, an AI agent can discover EmblemAI's capabilities, negotiate payment terms, and execute paid API calls without any human intervention or pre-registration. In practice, the discovery flow is entirely machine-driven: using a standard fetch, the agent hits /.well-known/x402, parses the price list, picks a tool, signs a payment, and executes the call in under a second. For example, an agent needing a Solana token price pays $0.01 in USDC and gets the response in a single HTTP round trip — no API key, no account, no onboarding.

How does EmblemAI's pay-as-you-go billing work?

EmblemAI's CLI is a pay-per-use billing system that agents configure from the command line, with tool pricing ranging from $0.01 for a single market-data query to $0.10 for a cross-chain analysis. Our default mode is pay_per_request, which settles each tool call individually in USDC via the built-in wallet. In practice, we ship the CLI so a user can enable billing, set the payment token, and pick a mode in three commands. For example, an agent running a Solana trading strategy configures USDC payment, picks per-request mode, and starts calling tools immediately:

# Check payment status
emblemai
> /payment

# Enable pay-as-you-go
> /payment enable

# Set payment token
> /payment token USDC

# Set per-request billing
> /payment mode pay_per_request

With x402, the same billing system extends to external agents. Any x402-compatible agent can call EmblemAI's tools without an API key — just a wallet with stablecoins. The pricing is per-call: an agent pays only for the exact tools it uses, whether that is a single Solana token swap, a $0.02 Birdeye trending-tokens query, or a complex cross-chain yield analysis spanning all 7 supported blockchains (Solana, Ethereum, Base, BSC, Polygon, Hedera, Bitcoin).

How do you build an x402-aware agent?

You build an x402-aware agent in four HTTP steps: (1) make the initial request, (2) parse the 402 payment requirements if the server returns one, (3) sign a payment with a wallet, (4) retry the same request with an X-PAYMENT header. The pattern is identical for every x402-protected endpoint, not just EmblemAI, so the same client code works across Cloudflare, Nous Research, Vercel, and any other x402 service.

In practice, the minimal JavaScript client fits in about 30 lines including comments. For example, here is a complete x402 client using only fetch and a wallet SDK:

async function x402Request(url, wallet) {
  // Step 1: Make the initial request
  const response = await fetch(url);

  if (response.status !== 402) {
    return response.json(); // No payment needed
  }

  // Step 2: Parse payment requirements
  const paymentReq = await response.json();
  const option = paymentReq.accepts[0]; // Pick first option

  console.log(`Payment required: ${option.maxAmountRequired} base units of ${option.asset} on ${option.network}`);

  // Step 3: Construct and sign payment
  const payment = await wallet.signPayment({
    to: option.payTo,
    amount: option.maxAmountRequired,
    asset: option.asset,
    network: option.network
  });

  // Step 4: Retry with payment header
  const paidResponse = await fetch(url, {
    headers: { "X-PAYMENT": payment.signature }
  });

  return paidResponse.json();
}

The Coinbase x402 SDK provides production-ready client and server implementations in TypeScript, Go, and Python, so you rarely need to write this loop by hand. The server-side integration is even smaller:

import { paymentMiddleware } from "@coinbase/x402";

app.use(
  paymentMiddleware({
    "GET /api/market-data": {
      accepts: [{ network: "base-mainnet", asset: "USDC" }],
      maxAmountRequired: "10000", // $0.01
      description: "Real-time market analysis"
    }
  })
);

Coinbase operates a hosted facilitator service that handles payment verification and settlement. It supports Base, Polygon, and Solana, with a free tier of 1,000 transactions per month, then $0.001 per transaction after that — which for most agent workloads is effectively free.

Why does x402 matter for the agent economy?

x402 matters because it unbundles API access into per-call micropayments, compressing account creation, billing agreements, and invoicing cycles into a single HTTP round trip. For EmblemAI specifically, that turns 200+ trading tools into individually purchasable units priced from $0.01 per call — an agent discovers a tool, pays for it, and consumes it in under a second, without ever creating an account. Traditional API monetization requires a human in the loop at signup; x402 removes that bottleneck entirely.

In practice, an EmblemAI agent can pay $0.01 for a single market-data query, $0.05 for a swap execution, or $0.10 for a cross-chain analysis spanning all 7 supported blockchains. Each tool is priced at its marginal cost instead of bundled into a monthly subscription, which is the first pricing model that actually matches how autonomous agents operate. An agent running a trading strategy only pays when it consumes a tool, so idle time costs nothing.

Combining EmblemAI's multi-chain wallet infrastructure with x402 payments creates a complete agent commerce stack: agents can both earn and spend crypto autonomously. For example, an agent can execute a profitable trade using EmblemAI's tools, then immediately spend a portion of those profits on a data feed from another x402-protected service, all without human involvement — the full loop of earn-and-spend, software-to-software, via a single wallet identity.

What are x402's current limitations?

First off, x402 has four current limitations worth naming before building production systems on it.

Daily volume is thin. CoinDesk reported around $28,000 in total daily x402 volume in March 2026, which means the protocol is still in its infrastructure phase rather than mass adoption.
Per-network payment finality introduces variable latency depending on the chain you settle on, especially for networks with long confirmation times.
The facilitator model adds a centralized dependency to an otherwise decentralized protocol, with Coinbase's hosted facilitator handling the majority of verification traffic in practice.
Finally, the agent-wallet landscape is fragmented. Coinbase, MoonPay, and EmblemAI each ship different approaches to agent financial identity, so there is no single wallet standard an agent-builder can assume.

These are solvable engineering problems, not fundamental design flaws. The HTTP 402 status code waited 29 years for the right infrastructure. Stablecoins now handle settlement, AI agents are generating real demand, and Cloudflare's pay-per-crawl rollout is the leading indicator to watch — when a Tier-1 CDN puts x402 in front of hundreds of millions of requests, the ecosystem will thicken fast.

EmblemAI's x402 discovery endpoint is live at agenthustle.ai. The full protocol specification is at x402.org. Coinbase's developer documentation is at docs.cdp.coinbase.com/x402. The EmblemAI CLI is available via npm install -g @emblemvault/agentwallet, with documentation at emblemvault.dev.

How to Give Your AI Agent a Multi-Chain Crypto Wallet in 5 Minutes

EmblemAI — Tue, 14 Apr 2026 06:10:35 +0000

Most AI agents hit the same wall: they can reason about money yet cannot touch it. EmblemAI solves this with a single npm package that gives any AI agent a deterministic crypto wallet spanning 7 blockchains and access to 200+ autonomous trading tools. This tutorial walks you through install, authentication, and your first on-chain operation.

The problem: agents without wallets are spectators

Most agent frameworks ship with no native financial capability. Developers end up stitching together separate SDKs for each chain, managing private keys manually, and writing custom swap logic for every DEX. A single cross-chain operation can require three or four different libraries, each with its own authentication model.

Coinbase recognized this gap and launched its Agentic Wallets product in late 2025, providing wallets with programmable guardrails. EmblemAI takes a different approach: a CLI-first tool that any agent framework can shell out to, with 200+ pre-built trading tools across 14 categories and support for Solana, Ethereum, Base, BSC, Polygon, Hedera, and Bitcoin out of the box.

Step 1: Install the CLI

EmblemAI ships as a global npm package. One command, no configuration files.

npm install -g @emblemvault/agentwallet

This installs the emblemai binary. It requires Node.js 18 or later. Verify the install:

emblemai --help

The package is open source and auditable. You can compare the published npm contents against the GitHub repository at any time using npm pack --dry-run.

Step 2: Authenticate your agent

EmblemAI supports two authentication modes. For interactive development, browser auth opens a login modal. For agents running in production, password auth works without a browser.

# Interactive mode -- opens browser for login
emblemai

# Agent mode -- zero-config, auto-generates a wallet
emblemai --agent -m "What are my wallet addresses?"

Each password deterministically generates the same wallet every time. Different passwords produce different wallets. This means you can give each agent its own isolated wallet simply by assigning a unique password:

# Agent Alice gets her own wallet
emblemai --agent -p "agent-alice-wallet-001" -m "What are my balances?"

# Agent Bob gets a completely separate wallet
emblemai --agent -p "agent-bob-wallet-002" -m "What are my balances?"

Credentials are encrypted at rest using AES-256-GCM via dotenvx. The encryption key never leaves the local machine.

Step 3: Query balances across all chains

Once authenticated, the agent has wallet addresses on every supported chain. A single natural-language query returns balances across all 7 blockchains simultaneously.

emblemai --agent -m "Show my balances across all chains"

The agent wallet provides addresses across these chain types:

Chain	Address Type
Solana	Native SPL wallet
Ethereum, Base, BSC, Polygon	Shared EVM address
Hedera	Account ID (0.0.XXXXXXX)
Bitcoin	Taproot, SegWit, and Legacy

This is one wallet identity spanning 7 chains. No separate setup per chain. No bridge configuration.

Step 4: Execute your first swap

EmblemAI interprets natural language, so your agent does not need to construct raw transaction parameters. The tool handles routing, slippage, and gas estimation.

emblemai --agent -m "Swap 20 dollars worth of SOL to USDC on Solana"

The agent operates in safe mode by default. All wallet-modifying actions, including swaps, sends, transfers, and order placement, require explicit confirmation before execution. Read-only operations like balance checks and market data queries execute immediately.

For scripted pipelines, output can be piped to other tools:

emblemai --agent -m "What is my SOL balance?" | jq .

Step 5: Multi-chain operations

The real power is cross-chain. EmblemAI supports bridge operations via ChangeNow, DeFi position management, limit orders, and market data aggregation from CoinGlass, DeFiLlama, Birdeye, and LunarCrush.

# Cross-chain bridge
emblemai --agent -m "Bridge 50 USDC from Ethereum to Solana"

# DeFi operations
emblemai --agent -m "What are the best yield opportunities for USDC right now?"

# Market intelligence
emblemai --agent -m "What tokens are trending on Solana today?"

The 200+ tools are organized into 14 categories: trading, DeFi, market data, NFTs, bridges, memecoins, predictions, and more. The AI dynamically selects the right tools based on the query. No manual tool configuration required.

Integration with any agent framework

Because emblemai is a CLI binary, any system that can shell out to a command can use it. This works with CrewAI, AutoGPT, LangChain agents, Claude with tool use, or custom Python scripts:

import subprocess
import json

def agent_wallet_query(message: str) -> str:
    result = subprocess.run(
        ["emblemai", "--agent", "-m", message],
        capture_output=True, text=True
    )
    return result.stdout

# Any agent can now trade
balances = agent_wallet_query("Show my portfolio summary")

EmblemAI also provides an MCP (Model Context Protocol) server, which means Claude Code, GitHub Copilot, Gemini CLI, and other MCP-compatible tools can access wallet operations natively without shelling out. The platform additionally supports Google's A2A (Agent-to-Agent) protocol for direct agent interoperability.

What you get

EmblemAI provides 200+ autonomous trading tools across 7 blockchains in 14 categories, accessible through a single npm install. The deterministic wallet model means one password equals one persistent identity across all chains.

The package is open source, the credentials are encrypted at rest, and every transaction requires explicit human approval. Full documentation is available at emblemvault.dev, and the npm package is at @emblemvault/agentwallet.