dfmi x402 market
Shop the dfmi x402 agent market: find services, get quotes, free test dUSD, capped buying.
Runs on your machine from its package; the steps are below.
What it does
- Reads
- Writes
- High impact
At most: moves money, runs code or commands, deletes data, or sends messages for you.
What it costs
FreeOdel charges nothing per call. The publisher may charge for its own service.
Runs locally over stdio
This server isn't hosted — your MCP client launches it from a package registry. Use one of the commands below, or drop the config into your client (e.g. Claude Desktop).
Run
npx -y dfmi-market-mcp
MCP client config
{
"mcpServers": {
"dfmi-x402-market": {
"command": "npx",
"args": [
"-y",
"dfmi-market-mcp"
]
}
}
}dfmi
The control plane for agent payments. Bounded, revocable, intent-scoped credentials for software agents that spend on their own — enforced in the authorization path, not in a log you read after the loss.
dfmi is an open-source research project. It runs on a live, purpose-built EVM chain (eip155:112172) with a test settlement unit (dUSD) and an x402 facilitator, so that every idea in this repository is exercised by real transactions rather than described in a whitepaper.
- Concepts and walkthrough: https://dfmi.me
- Live market, wallet, faucet, developer entry point: https://dfmi.app
- Contact: admin@dfmi.app
dfmi is experimental and non-commercial. dUSD is a test unit with no monetary value. See the Legal Notice and Terms.
The problem
In a raw x402 / EIP-3009 setup, an autonomous buying agent holds a funded key, and a signed payment authorization is a bearer instrument. If the agent is compromised, the only "revocation" is draining the wallet: you attack the money, not the authority. Coding agents inherited a control plane (sandboxes, git revert, CI and review gates). Money has nothing to inherit.
dfmi builds that missing layer as three thin, composable contracts.
The three layers
| Layer | Question it answers | Contract | Key entry points |
|---|---|---|---|
| Credential | How much, until when — and can it be stopped instantly? | contracts/SessionKeyWallet.sol | grantSession(key, cap, expiry) · revokeSession(key) · pay(...) · ownerWithdraw(...) |
| Identity | Who is the continuing agent behind rotating keys? | contracts/AgentRegistry.sol | register(name) · bindKey(agentId, key) · unbindKey(key) · deactivate(agentId) |
| Intent | What is the agent allowed to buy? | contracts/IntentSessionWallet.sol + contracts/ServiceRegistry.sol | grantSession(key, cap, expiry, intentMask) · allowed(key, payee) · ServiceRegistry.register(payTo, category, label) |
Credential. The agent's operating funds live in the wallet contract, never in the agent's own key. The owner grants a session key with a spend cap and an expiry; the agent signs EIP-712 Pay(to, amount, nonce, deadline) messages offline with that session key, and anyone (a relayer, the facilitator) submits them. pay() enforces: granted, not revoked, not expired, within cap, correct nonce, valid signature. One revokeSession() transaction freezes a compromised agent; every later payment it attempts reverts. The owner can always withdraw.
Identity. AgentRegistry is a single, global, append-only table. An owner registers an agent once and binds every session key it is ever granted to that agentId. History and reputation aggregate by agent across key rotations, and the kill switch gains a second grade: revokeSession cancels one card; deactivate fires the agent.
Intent. IntentSessionWallet is the credential wallet with one addition: each session carries an intentMask, a 256-bit set of allowed service categories. ServiceRegistry gives every payout address a public category (1 = market-data, 2 = ai-answers, 3 = api-tools, 4 = media, 5 = compute, 6..255 = open). pay() resolves the payee's category and enforces membership in the authorization path, next to the revocation gate. "Only market-data services, 1.00 dUSD, 7 days" is one grant. The agent-side flow is unchanged: same EIP-712 Pay, same relayer path; intent lives in the grant, not in the signature.
Stated limits, on purpose: ServiceRegistry registration is first-come and self-declared, so a malicious seller can mis-categorize itself once. What this MVP proves is that intent enforcement needs no new cryptography and no synchronous issuer hop. Trustworthy category attestation (curator signatures, stake-and-challenge) is the next problem — an attestation problem, not an enforcement one.
What is in this repository, and what is not
This repository contains the protocol layer: the four contracts above, the build and deploy scripts for the identity and intent layers, and a reference buyer client.
| Path | What it is |
|---|---|
contracts/ | The three layers, as Solidity ^0.8.20 (evmVersion: byzantium for the AuRa chain) |
build-agent-registry.mjs | Compiles AgentRegistry.sol to agent-registry.json (abi, bytecode) |
deploy-agent-registry.mjs | Deploys the global AgentRegistry and wires its address into the facilitator config |
build-intent.mjs | Compiles ServiceRegistry.sol and IntentSessionWallet.sol |
deploy-intent.mjs | One-shot intent-layer deployment: deploys the registry and wallet, registers a category, funds the wallet, and grants a session scoped to market-data only |
buyers/ | buy.mjs: an x402 buyer / verification client (exact scheme, EVM) that runs the full loop — 402 → offline signature → paid retry → settlement receipt |
paykit/ | Seller-side toolbox as an MCP server: create_invoice (unique exact amount), check_payment (reads the chain; unknown is never "unpaid"), send_reminder (drafts only), list_invoices. Read-only, holds no keys. Plus pay.mjs, a buyer-side helper that signs offline and settles through the facilitator with no gas |
buykit/ | Buyer-side toolbox as an MCP server: check_budget, pay_invoice (within a SessionKeyWallet session, via the facilitator, idempotent), list_purchases. Holds a bounded session key, never the owner's key. grant.mjs is the owner's issue/revoke tool |
seller-agent/ | Reference selling agent: same rules and code-enforced delivery gate on three backends (Claude Agent SDK, any OpenAI-compatible endpoint such as Ollama Cloud, Codex CLI via MCP), plus seller-serve.mjs, the seller as an HTTP service another agent can buy from. Delivery happens only after paykit sees settlement on-chain |
buyer-agent/ | Reference buying agent on the same three backends; the owner's per-purchase limit is passed into buykit as max_amount, so the bound is code, not memory |
market-mcp/ | Marketplace MCP server for any MCP client (Claude, Cursor, Codex): dfmi_list_services, dfmi_quote, dfmi_wallet, dfmi_create_wallet, dfmi_claim_faucet, dfmi_buy. Per-call cap, session budget and testnet-only default are enforced in code. Published as dfmi-market-mcp on npm and io.github.dfmi-app/dfmi-market on the MCP Registry: claude mcp add dfmi -- npx -y dfmi-market-mcp |
agents-page/ | The public live page at dfmi.app/agents: agent-to-agent settlements from the facilitator ledger and grant/revoke events from the chain, side by side |
Not in this repository, by design: the facilitator (payment verification and settlement service), the chain node configuration, the dUSD contract, and the market front end. These are the operating layer; they run the live network at dfmi.app and are kept separate from the protocol contracts so the contracts can be read, reused, and audited on their own.
Quick start
Build and deploy the identity registry (requires Node 18+, solc, ethers, and a .env with DEPLOYER_PRIVATE_KEY; never commit .env):
node build-agent-registry.mjs
node deploy-agent-registry.mjs
Buy something on the live market with the reference client (claim test dUSD first from the faucet at dfmi.app):
cd buyers
npm install
cp .env.example .env # add BUYER_PRIVATE_KEY
node buy.mjs --help
See buyers/README.md for the full claim → buy → read flow.
Timeline
| When | What |
|---|---|
| May 2026 | Design started: revocation belongs in the credential, not the balance |
| May 2026 | dfmi chain (eip155:112172), dUSD, and the x402 facilitator brought up |
| May 2026 | SessionKeyWallet (v1: cap, expiry, revoke) deployed and exercised by live purchases |
| 2 August 2026 | dfmi.app and dfmi.me public; Terms, Privacy, and Legal Notice effective |
| 17 August 2026 | Protocol contracts and reference client published in this repository |
| 19 August 2026 | AgentRegistry (identity layer) deployed |
| 20 August 2026 | IntentSessionWallet + ServiceRegistry (intent layer) deployed |
| 6 September 2026 | First agent-to-agent purchase settled on dfmi: seller agent invoiced with paykit, buyer agent paid from a SessionKeyWallet session through buykit and the facilitator, seller verified on-chain and delivered. Reproduced on Claude, glm-5.3 and gpt-6-astra; then end to end with no human between offer and goods (seller-serve.mjs + buyer.mjs) |
The credential layer ran against real transactions for three months before this repository was made public; the public commit history begins at publication, not at the start of the work.
Design principles
- The decision lives in the code path, not in the review. A transaction that violates a grant does not fail an audit; it fails to exist.
- Simple, binary rules. Cap, expiry, allowed category. Yes or no. A rule that needs interpretation is a rule an agent can argue with.
- Revocation is cheap, custody is separate. The owner key never enters the agent. Revoking a session costs one transaction and never touches the principal.
- Composable, not lock-in. dfmi is a layer above settlement. It assumes money that settles instantly and at par, and asks the question the rail cannot: was this agent allowed to send it at all?
License
MIT. See LICENSE. Copyright (c) 2026 dfmi Labs contributors.
