English Français العربية

dfmi x402 market

Registre officiel IA et agents

Shop the dfmi x402 agent market: find services, get quotes, free dUSD points, capped buying.

Code source Site web Documentation

Installation

Ajoutez ceci à la configuration MCP de votre client (Claude Desktop : claude_desktop_config.json ; Cursor : .cursor/mcp.json ; VS Code et les autres utilisent la même forme « mcpServers »).

NPM package dfmi-market-mcp
Claude Code 
claude mcp add dfmi-x402-market -e 'DFMI_BUYER_PRIVATE_KEY=<your dfmi_buyer_private_key>' -e 'DFMI_MAX_PRICE=<DFMI_MAX_PRICE>' -e 'DFMI_SESSION_BUDGET=<DFMI_SESSION_BUDGET>' -e 'DFMI_ALLOW_MAINNET=<DFMI_ALLOW_MAINNET>' -- npx -y dfmi-market-mcp@0.1.1
Configuration JSON (Claude Desktop, Cursor, VS Code) 
{
    "mcpServers": {
        "dfmi-x402-market": {
            "command": "npx",
            "args": [
                "-y",
                "dfmi-market-mcp@0.1.1"
            ],
            "env": {
                "DFMI_BUYER_PRIVATE_KEY": "<your dfmi_buyer_private_key>",
                "DFMI_MAX_PRICE": "<DFMI_MAX_PRICE>",
                "DFMI_SESSION_BUDGET": "<DFMI_SESSION_BUDGET>",
                "DFMI_ALLOW_MAINNET": "<DFMI_ALLOW_MAINNET>"
            }
        }
    }
}

Variables d'environnement

  • DFMI_BUYER_PRIVATE_KEY secret Optional throwaway buyer key. If unset, dfmi_create_wallet makes one in ~/.dfmi.
  • DFMI_MAX_PRICE Hard cap per purchase (default 0.10).
  • DFMI_SESSION_BUDGET Total spend cap per server run (default 1.00).
  • DFMI_ALLOW_MAINNET Set to 1 to allow mainnet payments. Off by default.

Documentation

Tirée du README du projet sur GitHub, actualisée chaque semaine. Les liens ouvrent GitHub.

Sommaire
  1. dfmi
  2. The problem
  3. The three layers
  4. What is in this repository, and what is not
  5. Quick start
  6. Timeline
  7. Design principles
  8. License

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.

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

LayerQuestion it answersContractKey entry points
CredentialHow much, until when — and can it be stopped instantly?contracts/SessionKeyWallet.solgrantSession(key, cap, expiry) · revokeSession(key) · pay(...) · ownerWithdraw(...)
IdentityWho is the continuing agent behind rotating keys?contracts/AgentRegistry.solregister(name) · bindKey(agentId, key) · unbindKey(key) · deactivate(agentId)
IntentWhat is the agent allowed to buy?contracts/IntentSessionWallet.sol + contracts/ServiceRegistry.solgrantSession(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.

PathWhat it is
contracts/The three layers, as Solidity ^0.8.20 (evmVersion: byzantium for the AuRa chain)
build-agent-registry.mjsCompiles AgentRegistry.sol to agent-registry.json (abi, bytecode)
deploy-agent-registry.mjsDeploys the global AgentRegistry and wires its address into the facilitator config
build-intent.mjsCompiles ServiceRegistry.sol and IntentSessionWallet.sol
deploy-intent.mjsOne-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

WhenWhat
May 2026Design started: revocation belongs in the credential, not the balance
May 2026dfmi chain (eip155:112172), dUSD, and the x402 facilitator brought up
May 2026SessionKeyWallet (v1: cap, expiry, revoke) deployed and exercised by live purchases
2 August 2026dfmi.app and dfmi.me public; Terms, Privacy, and Legal Notice effective
17 August 2026Protocol contracts and reference client published in this repository
19 August 2026AgentRegistry (identity layer) deployed
20 August 2026IntentSessionWallet + ServiceRegistry (intent layer) deployed
6 September 2026First 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.

Questions fréquentes

Qu'est-ce que dfmi x402 market ?

Shop the dfmi x402 agent market: find services, get quotes, free dUSD points, capped buying.

Comment installer dfmi x402 market ?

Il s'exécute sur votre machine. Dans Claude Code : claude mcp add dfmi-x402-market -e 'DFMI_BUYER_PRIVATE_KEY=<your dfmi_buyer_private_key>' -e 'DFMI_MAX_PRICE=<DFMI_MAX_PRICE>' -e 'DFMI_SESSION_BUDGET=<DFMI_SESSION_BUDGET>' -e 'DFMI_ALLOW_MAINNET=<DFMI_ALLOW_MAINNET>' -- npx -y dfmi-market-mcp@0.1.1. Pour les autres clients, collez la configuration JSON de cette page dans leurs réglages MCP.

Faut-il une clé API pour dfmi x402 market ?

Oui. Il attend DFMI_BUYER_PRIVATE_KEY, à renseigner dans sa configuration.

dfmi x402 market est-il open source ?

Oui. Son code est sur GitHub sous licence MIT.

Qui maintient dfmi x402 market ?

Il est publié par dfmi-app. AI.tn le référence sans le maintenir ni le recommander.

Issu du registre MCP officiel. Être listé n'est pas une recommandation : vérifiez le code et les permissions d'un serveur avant de lui donner accès à vos données.