Query ZeroDust chain support, wallet balances, sweep quotes, sweep status/history, and service info (no sweep execution tool).
zerodust_get_chains: List supported blockchain chains with chain IDs, names, native tokens, and contract addresses.
zerodust_get_balances: Check native gas token balances across all supported chains for a wallet, showing sweepable balances and USD values.
zerodust_get_quote: Get a sweep quote for one chain, including estimated received amount, fee breakdown, and a 60-second quote ID.
zerodust_get_sweep_status: Check a submitted sweep’s status (pending, simulating, executing, bridging, completed, failed), tx hash, and errors.
zerodust_list_sweeps: List past sweeps for a wallet address with status and amounts, with an optional result limit.
zerodust_info: Get ZeroDust service information, including what it does, fee structure, and usage guidance.
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.
Empty a wallet's native gas balance on an EVM chain to exactly 0.
A normal transfer cannot send a whole native balance, because paying for the transfer uses the token
being sent. ZeroDust sends all of it, to any address on the same chain or bridged to another chain,
and the wallet ends at exactly 0 wei. Live at zerodust.xyz, with an API at
https://api.zerodust.xyz and developer docs at zerodust.xyz/docs.
This repository holds the contracts, the TypeScript SDK and the agent packages.
Sponsored chains (EIP-7702): the wallet signs a SweepIntent and two EIP-7702 authorizations
(one delegating to the ZeroDust contract, one removing it afterwards). A ZeroDust sponsor executes
the sweep and pays the gas, reimbursed from the swept balance. The contract runs as the wallet and
reverts unless the balance ends at exactly 0.
MetaMask without a key: MetaMask's Advanced Permissions (ERC-7715) grant
ZeroDustPermissionRouter a one-time allowance per chain; one EIP-712 signature covers every chain.
The router redeems it, requires exactly 0, and settles like the contract. 16 chains.
Direct chains (no EIP-7702): the wallet sends its own legacy transactions, sized to the wei by
the API's planner (22 chains). On OP-stack chains with an L1 data fee it goes through
ZeroDustGuard; on ZK-stack chains a ZeroDust paymaster pays the gas.
What arrives: the destination's native gas, carried by Relay, Across (ETH to ETH), Stargate or Gas.zip, whichever delivers the most. A few chains whose coin no gas bridge carries deliver it as a token instead (Mitosis, Endurance, Intuition, Telos, 0G), said plainly in the quote. On request a sweep can also go into the chain's own bridge to Ethereum (to BNB Chain for opBNB), which the recipient proves and claims there later; Gravity's G and Fraxtal's FRAX arrive on Ethereum as the G and FXS tokens.
Related MCP server: ows-mcp-wallet
The agent packages (@zerodust/mcp-server, @zerodust/ai-sdk, @zerodust/langchain) are paused
and deprecated on npm, and the hosted MCP endpoint and agent key signup are switched off. The local
MCP server and the SDK still sweep through the public API with your own key; keys issued before keep
their rate limits. To sweep, use zerodust.xyz.
Package | Use |
TypeScript client and agent ( | |
MCP server, run locally (paused) | |
LangChain tools (paused) | |
Vercel AI SDK tools (paused) |
Contract | Address (same on every chain, CREATE2) | Where |
ZeroDustSweep ( |
| the 57 sponsored chains below |
ZeroDustPermissionRouter v2 ( |
| 16 chains with MetaMask Advanced Permissions |
ZeroDustGuard ( |
| Blast, Boba |
ZeroDustPaymaster ( |
| zkSync Era, Abstract, Lens |
All are immutable: no admin functions, no upgrades, no pause (the paymaster's owner can only change its approver and withdraw its float). The sweep contract's sponsor address is fixed in its bytecode.
57 sponsored chains, generated from the live API (GET https://api.zerodust.xyz/chains):
Chain | ID | Token | Chain | ID | Token |
Ethereum | 1 | ETH | Arc | 5042 | USDC |
Optimism | 10 | ETH | Superseed | 5330 | ETH |
BNB Chain | 56 | BNB | Kaia | 8217 | KAIA |
Gnosis | 100 | xDAI | Base | 8453 | ETH |
Unichain | 130 | ETH | Plasma | 9745 | XPL |
Polygon | 137 | POL | 0G | 16661 | 0G |
Sonic | 146 | S | Apechain | 33139 | APE |
Manta Pacific | 169 | ETH | Mode | 34443 | ETH |
X Layer | 196 | OKB | Mythos | 42018 | ETH |
Fraxtal | 252 | FRAX | Arbitrum | 42161 | ETH |
Shape | 360 | ETH | Arbitrum Nova | 42170 | ETH |
World Chain | 480 | ETH | Celo | 42220 | CELO |
Endurance | 648 | ACE | Hemi | 43111 | ETH |
Stable | 988 | gUSDT | Zircuit | 48900 | ETH |
Lisk | 1135 | ETH | Ink | 57073 | ETH |
Intuition | 1155 | TRUST | Linea | 59144 | ETH |
Sei | 1329 | SEI | BOB | 60808 | ETH |
DATA Network | 1514 | DATA | Berachain | 80094 | BERA |
Pharos | 1672 | PROS | Codex | 81224 | ETH |
Reya | 1729 | ETH | Doma | 97477 | ETH |
Metal L2 | 1750 | ETH | Plume | 98866 | PLUME |
Soneium | 1868 | ETH | Mitosis | 124816 | MITO |
Ronin | 2020 | RON | Taiko | 167000 | ETH |
Morph | 2818 | ETH | HPP | 190415 | ETH |
RISE | 4153 | ETH | Scroll | 534352 | ETH |
MegaETH | 4326 | ETH | Gensyn | 685689 | ETH |
Robinhood Chain | 4663 | ETH | Katana | 747474 | ETH |
Mantle | 5000 | MNT | Zora | 7777777 | ETH |
Somnia | 5031 | SOMI |
Regenerate or check this table with node scripts/generate-chain-docs.mjs (--check runs in CI); do
not hand-edit it. The 22 direct chains are listed by GET https://api.zerodust.xyz/direct/chains:
Flare, Cronos, Rootstock, Telos, XDC, Fuse, Monad, opBNB, Lens, Boba, zkSync Era, Flow EVM, HyperEVM,
Metis, Vana, Gravity, Abstract, Immutable zkEVM, Etherlink, Avalanche, Blast and Ethereal. Destinations are
any EVM chain a bridge delivers native gas to (GET /destinations?fromChainId=), over 100 from Base.
1% of the swept value, at least $0.05 and at most $0.50; balances under $1 pay 5%, with no minimum.
On top: the sweep's gas (and the L1 data fee on rollups) and, cross-chain, the bridge's fee. The
signed maxTotalFeeWei caps what can be taken, so a gas spike cannot exceed what you agreed to.
No custody: every sweep is one atomic transaction from the wallet itself.
The signed intent caps the fee and names the destination; for a bridge route routeHash
(keccak256(callData)) binds the signature to that exact call.
Every sponsored transaction is simulated before it is sent.
ERC-7201 namespaced storage, so the contract's nonce never collides with another EIP-7702 app.
Internal security review, 7 rounds, 16 issues found and fixed; contract tests drive a real EIP-7702 delegation and are mutation-verified. Not externally audited, and no audit is currently funded. Details: contracts/SECURITY.md, contracts/SECURITY_REPORT.md.
contracts/ Foundry: ZeroDustSweepMainnet.sol, ZeroDustPermissionRouter.sol, ZeroDustGuard.yul,
tests, deploy scripts and broadcasts (README, SPECIFICATION, DEPLOYMENT, SECURITY)
contracts-zk/ ZeroDustPaymaster for ZK-stack chains (Hardhat + zksolc)
sdk/ @zerodust/sdk
packages/ @zerodust/mcp-server, @zerodust/ai-sdk, @zerodust/langchain
skills/ an agent skill for ZeroDust
scripts/ generate-chain-docs.mjsMIT, see LICENSE.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1zerodust_get_chainszerodust_get_sweep_statuszerodust_infoScored across 3 tools
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.
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
Non-custodial DEX aggregator for autonomous AI agents: best-price swaps on 8 chains, no API key.
