This server lets you check, quote, and track native gas token sweeps across 25+ supported blockchains — enabling you to exit a chain with exactly 0 balance remaining.
zerodust_info: Get general information about ZeroDust, including how it works, its fee structure, and usage guidance.
zerodust_get_chains: Retrieve all supported chains (25 mainnets) with chain IDs, native token names, and contract addresses.
zerodust_get_balances: Check native gas token balances across all supported chains for a given wallet address, including USD values and which chains have sweepable amounts.
zerodust_get_quote: Get a price quote for sweeping from one chain to another, including fee breakdown and estimated receive amount. Quotes expire in 60 seconds.
zerodust_get_sweep_status: Poll the status of a previously submitted sweep by its ID, with stages like pending, simulating, executing, bridging, completed, or failed — plus transaction hashes where available.
zerodust_list_sweeps: View the sweep history for a wallet address, including statuses and amounts.
Note: This hosted server is read-only — it holds no keys and cannot execute sweeps. Actual sweep execution requires running the
@zerodust/mcp-serverpackage locally with signing credentials configured.
Allows sweeping native BNB on BNB Chain to other supported chains or same-chain, achieving exactly zero balance.
Allows sweeping native ETH on Ethereum mainnet to other supported chains or same-chain, achieving exactly zero balance.
Allows sweeping native ETH on Optimism to other supported chains or same-chain, achieving exactly zero balance.
Allows sweeping native POL on Polygon to other supported chains or same-chain, achieving exactly zero balance.
Exit a blockchain completely - transfer 100% of your native gas balance via EIP-7702
ZeroDust is an intent-based exit system that enables users to sweep their entire native gas token balance to exactly zero via EIP-7702 sponsored execution.
Agents accumulate dust as a byproduct of existing. Anything doing multi-chain work — arbitrage, bridging, testing, deployment — ends up with stranded gas on chains it will never touch again. A human notices and shrugs; an unattended agent leaks capital indefinitely.
The hosted MCP server needs nothing installed. Point any MCP client at:
https://api.zerodust.xyz/mcpThat is enough to find out whether an address has anything stranded and what recovering it would cost. It is read-only, because it holds no keys.
{
"mcpServers": {
"zerodust": {
"command": "npx",
"args": ["@zerodust/mcp-server"],
"env": {
"ZERODUST_ALLOW_EXECUTE": "true",
"ZERODUST_SIGNER_MODULE": "./my-signer.mjs"
}
}
}
}Read-only by default. Sweeping needs the explicit opt-in above plus a signing key, and there are four ways to supply one so a raw key never has to sit in a config file:
Variable | Key lives in |
| your custody provider — any module returning a viem |
| an encrypted V3 keystore, with the password in a separate file |
| a file on disk, not in the config |
| the config (simplest, least private) |
Funds can only go to the agent's own address unless
ZERODUST_ALLOWED_DESTINATIONS says otherwise — so a prompt-injected agent still
cannot send funds somewhere you never approved.
Every sweep tool and every SDK sweep accepts dryRun. It fetches a real quote,
produces all three real signatures, and stops before submitting. Nothing is
broadcast and no balance moves:
"Do a dry run of sweeping my Arbitrum balance to Base"
There is deliberately no testnet mode: the API serves no testnet chains, so a
testnet flag would only return empty chain lists and failing quotes. dryRun
gives the same confidence against production.
The read-only tools work with no credential at all. For higher limits an agent
can issue itself a key with no human in the loop, via the zerodust_register_api_key
tool or directly:
curl -X POST https://api.zerodust.xyz/agent/register \
-H "Content-Type: application/json" \
-d '{"name": "my-agent", "agentId": "my-agent-1"}'
# -> { "apiKey": "zd_...", "rateLimits": { "perMinute": 300, "daily": 1000 } }Package | Use |
MCP (Claude Code, Claude Desktop, any MCP client) | |
TypeScript, direct — | |
LangChain tools | |
Vercel AI SDK tools |
Verified on mainnet (2026-07-21): Optimism → Base, source balance to exactly
0, delegation auto-revoked, 99.88% delivered, 23.2s end to end —
0x19456ea8….
Note on wallets: the browser UI needs the non-standard
wallet_signAuthorizationRPC, which no shipping wallet exposes yet (MetaMask #7836, Rabby #3411). Agents are unaffected — they hold their own keys and sign locally.
Related MCP server: ows-mcp-wallet
When users want to fully exit a blockchain, they face an impossible situation:
User has: 0.0008 ETH on Arbitrum
User wants: 0 ETH on Arbitrum (transfer everything to Base)
The Problem:
├── To send ETH, you need ETH for gas
├── If you send all your ETH, you can't pay gas
├── If you keep gas, you can't send all your ETH
└── Result: Small amount always strandedZeroDust is the only solution that enables complete chain exits for native gas tokens.
User connects wallet to ZeroDust
User selects source chain and destination (same-chain or cross-chain)
User signs ONE authorization (no gas needed)
ZeroDust sponsor executes the sweep
User receives funds on destination
Origin chain balance: EXACTLY ZERO
Case | Description | Example |
Cross-chain, same address | Exit to yourself on another chain | Arbitrum → Base (same wallet) |
Cross-chain, different address | Exit to another wallet on another chain | Arbitrum → Base (different wallet) |
Same-chain, different address | Consolidate to another wallet | Arbitrum → Arbitrum (different wallet) |
Post-Condition (enforced on-chain): Source balance = exactly 0 wei
Contract Address (same on all chains): 0x3732398281d0606aCB7EC1D490dFB0591BE4c4f2
The contract is deployed on 26 mainnets. 25 of those are live in the API — Apechain (33139) is deployed but disabled, because it turned out not to support EIP-7702.
Chain | ID | Token | Chain | ID | Token |
Ethereum | 1 | ETH | Mantle | 5000 | MNT |
Optimism | 10 | ETH | Superseed | 5330 | ETH |
BNB Chain | 56 | BNB | Base | 8453 | ETH |
Gnosis | 100 | xDAI | Plasma | 9745 | XPL |
Unichain | 130 | ETH | Mode | 34443 | ETH |
Polygon | 137 | POL | Arbitrum | 42161 | ETH |
Sonic | 146 | S | Celo | 42220 | CELO |
X Layer | 196 | OKB | Ink | 57073 | ETH |
Fraxtal | 252 | FRAX | BOB | 60808 | ETH |
World Chain | 480 | ETH | Berachain | 80094 | BERA |
Sei | 1329 | SEI | Scroll | 534352 | ETH |
Story | 1514 | IP | Zora | 7777777 | ETH |
Soneium | 1868 | ETH |
This table is generated from the live API, which is the only authoritative answer to what an integration can actually use:
node scripts/generate-chain-docs.mjs # regenerate
node scripts/generate-chain-docs.mjs --check # fail if a doc has drifted
curl https://api.zerodust.xyz/chains # the source of truthPlease do not hand-edit it. Earlier versions of this table claimed 26 live chains and named 1514 "Astar zkEVM", 5330 "Kaia" and 57073 "Redstone" — three chains that are not the ones deployed there. An agent that acts on a wrong chain name gets an error and reasonably concludes the service is broken.
The contract is also on 46 testnets, but the API serves no testnet chains, so
there is no testnet environment to integrate against. Use the dryRun option in
the SDK or the MCP server to exercise the full flow without moving funds.
See contracts/README.md for explorer links.
zerodust/
├── contracts/ # Smart contracts (Foundry)
│ ├── src/
│ │ ├── ZeroDustSweepMainnet.sol # Production contract
│ │ └── ZeroDustSweepTEST.sol # Testnet contract
│ ├── script/
│ │ └── DeployMainnet.s.sol # Mainnet deployment (CREATE2)
│ └── broadcast/ # Deployment logs
└── docs/┌─────────────────────────────────────────────────────────────┐
│ User's EOA │
│ (EIP-7702 delegated) │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ ZeroDustSweepMainnet (bytecode) │ │
│ │ │ │
│ │ executeSweep(intent, sig) │ │
│ │ │ │ │
│ │ ┌────────────┴────────────┐ │ │
│ │ ▼ ▼ │ │
│ │ MODE_TRANSFER (0) MODE_CALL (1) │ │
│ │ Same-chain sweep Cross-chain sweep │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ Transfer to Call bridge target │ │
│ │ destination (callTarget + callData) │ │
│ │ │ │ │
│ └─────────────────────────────────────┼────────────────┘ │
│ │ │
└────────────────────────────────────────┼─────────────────────┘
│
▼
┌─────────────────────────┐
│ External Bridge │
│ (Gas.zip) │
│ │
│ Delivers funds on │
│ destination chain │
└─────────────────────────┘No admin functions - Immutable after deployment
No upgradability - What you see is what you get
Unified SweepIntent - Single signed structure for all sweep types
Zero balance enforcement - Contract reverts if any balance remains
ERC-7201 storage - Prevents slot collisions with other EIP-7702 apps
Immutable sponsors - Stored in bytecode, not storage
Service Fee: 1% of swept value, with $0.05 minimum and $0.50 maximum.
Total Fee = Gas Reimbursement + Service Fee + Bridge Fee (if cross-chain)
Examples:
- $5 balance → $0.05 fee (1% = $0.05, at min) → User receives ~$4.95
- $10 balance → $0.10 fee (1%) → User receives ~$9.90
- $60 balance → $0.50 fee (max) → User receives ~$59.50contracts/README.md - Contract details and deployment
contracts/SPECIFICATION.md - Technical specification
contracts/DEPLOYMENT.md - Deployment guide
ZeroDust is designed with security as the top priority:
No fund custody - All operations are atomic, single-transaction
User-controlled limits - maxTotalFeeWei and minReceive signed by user
Mandatory simulation - Every transaction simulated before execution
routeHash binding - Signature bound to specific bridge route (cross-chain)
Internal security review - 7 rounds, 16 issues identified and fixed
External audit - Pending (required before full launch)
Smart Contract: Deployed on 26 mainnets + 46 testnets. 25 mainnets are enabled in the API; the API serves no testnets.
Contract | Status | Features |
ZeroDustSweepMainnet | Production | Unified SweepIntent, granular fees, sponsor model |
ZeroDustSweepTEST | Testnet | Same as mainnet, for testing |
See contracts/README.md for full deployment list.
The following testnets were tested and do not support EIP-7702:
Abstract, Lens, zkSync, Taiko, opBNB, Avalanche, Swell, Cyber, Boba, Metis, Fuse, Aurora, Flare, Vana, Corn, Rootstock, Apechain, IoTeX, Viction, XDC, Telos, Kava, EDU Chain, Gravity, Manta Pacific, Lightlink, Moonbase, Nibiru, Somnia, Rari, Blast, Xai, B3, Mezo, Chiliz, HashKey, Memecore
Note: Mainnet support may differ from testnet.
ZeroDust supports cross-chain sweeps via the MODE_CALL pattern:
callTarget: Bridge contract address
callData: Bridge-specific transaction data
routeHash: keccak256(callData) - binds signature to specific route
Primary Bridge: Gas.zip - 239+ chains, ~5 second delivery
MIT License - see LICENSE
Live on 25 mainnet chains. Contract: 0x3732398281d0606aCB7EC1D490dFB0591BE4c4f2
(same address on every chain, via CREATE2).
Get a list of all blockchain chains supported by ZeroDust for sweeping native gas tokens. Returns chain IDs, names, native tokens, and contract addresses.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks details on behavioral traits such as read-only nature, caching, or authentication requirements. It only states what it returns without disclosing side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and immediately specifies the output, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains what the tool returns and its purpose. However, it could mention that it is a read-only, safe operation, but overall it is complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description adds value by listing return fields, which is more than what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a list of supported blockchain chains and specifies the returned data (chain IDs, names, native tokens, contract addresses). This distinguishes it from siblings like zerodust_get_sweep_status and zerodust_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using this tool when you need the list of supported chains, but does not provide explicit guidance on when to use it versus alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a previously submitted sweep. Returns the current status (pending, simulating, executing, bridging, completed, failed), transaction hash if available, and error messages if failed.
| Name | Required | Description | Default |
|---|---|---|---|
| sweepId | Yes | The sweep ID returned from submitting a sweep |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes the return values (status, transaction hash, errors) and implies a read-only operation. It does not mention authentication or rate limits, but for a simple status check it is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action, and contains no unnecessary words. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is complete. It covers the return values (status, transaction hash, errors) and the input requirement, making the tool easy to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'sweepId' is fully described in the input schema (100% coverage). The description adds no additional meaning beyond what the schema provides, earning a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks the status of a previously submitted sweep and lists the returned fields. It distinguishes itself from sibling tools like 'zerodust_get_chains' and 'zerodust_info' by its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after submitting a sweep, but does not explicitly state when not to use it or provide alternatives. The context makes the usage fairly clear, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about ZeroDust service, including what it does, fee structure, and how to use it. Use this tool when the user asks about ZeroDust or needs to understand the service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates an information retrieval tool with no side effects, but does not explicitly state read-only behavior, cost, or rate limits. For a simple info tool, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then usage guideline. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the tool's purpose and usage. It mentions output content (what it does, fee, usage). However, it could be more specific about the return format, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100% (empty schema). Baseline 4 is appropriate since the description adds no param information but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides information about ZeroDust service, listing specific topics (what it does, fee structure, how to use it). It distinguishes from sibling tools like zerodust_get_chains and zerodust_get_sweep_status which are about specific aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool when the user asks about ZeroDust or needs to understand the service. It's clear for when to use, though it doesn't explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: listing chains, checking sweep status, and providing service info. No overlap between them.
All tools share the 'zerodust_' prefix and mostly follow verb_noun pattern ('get_chains', 'get_sweep_status'), though 'info' is a noun-only name, causing a minor inconsistency.
Three tools is on the low end for a sweeping service; it's minimal but could be acceptable if the service is very simple. However, the count feels slightly thin.
The server lacks a tool to actually submit a sweep, which is the core operation. Without it, the tool set is severely incomplete for the stated purpose of sweeping native gas tokens.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Gasless cross-chain for AI agents: 25 nodes incl. Solana & native Bitcoin. One signature, no gas.
Gasless, MEV-protected onchain token swaps for AI agents on 14 EVM chains, built on CoW Protocol.
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Cross-chain token swaps for autonomous agents on Base L2 and partner rails
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/andresdefi/zerodust'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
