EVM Trading

Balchemy Hub agents trade supported EVM tokens on Base through the 0x aggregator. The trading flow surfaces available pre-trade reports, simulations, policy checks, and provider source-health status before an eligible order can move through the authorized execution path.

What is this?

EVM trading in Balchemy routes swaps on Base (chain ID 8453) through the 0x Protocol exchange aggregator. 0x sources liquidity from Uniswap V2, Uniswap V3, Curve, and other Base DEXes to find an execution route. Your Hub agent can look up tokens, get quotes, request available security checks, inspect source-health caveats, and execute swaps through authorized commands, MCP/API calls, or rules that pass policy.

The same Rust trading engine that powers Solana trading handles EVM execution: it enforces risk policies, signs transactions using your custodial wallet, and reports lifecycle state back to the product flow.

Prerequisites

• A custodial EVM wallet created and set as primary on Base through the authorized Hub wallet flow (see Agent Wallet Management)
• The custodial wallet funded with ETH (for gas) and your input token (typically ETH or USDC on Base)
• A Hub agent key or runtime with trade scope where trading is intended

Warning: EVM trading is only available with custodial wallets. Delegate (external) wallets cannot sign transactions automatically. To execute EVM trades through Balchemy, you need a custodial wallet.

---

Two ways to trigger an EVM trade

1. Natural language or MCP/API intent

Use the authorized Hub/agent flow and describe the trade in plain English:

• "Buy $200 worth of USDC/BRETT on Base"
• "Swap 0.1 ETH for cbBTC on Base"
• "Sell my entire DEGEN position"

The agent flow resolves the token contract addresses, fetches a 0x quote, runs a pre-trade report, and presents a summary before submission. If the authorized rules/profile allow execution, eligible orders can move through the execution path without an additional chat confirmation.

2. Hub rules and runtime

Hub rules can produce EVM trade candidates on price movements, technical conditions, Signal Sources, or scheduled DCA intervals. The pipeline preserves quote, security status, policy checks, and explicit submitted/blocked/approval-required outcomes when a rule fires.

---

Fee structure

Balchemy charges a platform fee on every EVM swap using a pre-swap deduction followed by a distributeFee() call:

The fee deduction happens before the 0x quote is obtained, so the 0x aggregator routes the post-fee amount. The fee is distributed to the Balchemy fee collector contract and is visible in the transaction trace. 0x Protocol also charges a separate protocol fee, which is handled automatically by the engine.

---

Base as the primary EVM chain

Balchemy's EVM trading currently supports Base (Ethereum L2, chain ID 8453) as the primary chain. All requireBaseChainId checks in the engine enforce this. Passing any chain ID other than 8453 will return an error.

Support for Ethereum mainnet, Arbitrum, and Optimism is under consideration for a future release.

---

Pre-trade security checks

Before an EVM swap is submitted, the trading engine runs the available pre-trade checks and reports provider availability explicitly.

GoPlus Token Security (trading_security_goplus_token_security)

GoPlus Labs provides comprehensive token security scanning. It returns signals including:

• Is honeypot — Can the token be sold after purchase?
• Buy/sell tax — What percentage is deducted on buy and sell transactions?
• Proxy contract — Is the token contract upgradeable by the deployer?
• Owner concentration — How much do top wallets hold?
• Trading cooldown — Does the contract enforce a cooldown period between trades?
• Anti-whale mechanism — Does the contract limit maximum wallet size?

Honeypot Check (trading_security_honeypot_check)

Honeypot.is provides a fast, independent confirmation of whether a token's transfer function will revert on a sell attempt. A honeypot token lets you buy but never sell. This check defaults to chain ID 8453 (Base) when no chainId is specified.

EVM Pre-Trade Report (trading_evm_pretrade_report)

The combined pre-trade report requests the available GoPlus, Honeypot, and 0x quote evidence and returns a structured checklist. Provider failures, unconfigured sources, or stale evidence should remain visible as degraded or missing evidence instead of being treated as a clean pass.

---

Token metadata and resolution

Before trading an unfamiliar token, your Hub agent can resolve its contract details:

---

DEX pool tools

Your Hub agent can query on-chain DEX state directly using the EVM DEX tool family. These are useful for rules, market research, and candidate evaluation, not for executing trades:

---

Launchpad tools

Balchemy has provider-backed launchpad and token-research tools for Base where they are exposed by the current MCP tool list and source health is available. These tools are research inputs; they are not proof of exhaustive live Base launch coverage. Base realtime launch discovery is staged and source-health aware, so unavailable or disconnected providers must be shown as degraded or unavailable rather than as an empty market.

Pump.fun (Solana-style, Base variant)

Clanker (Farcaster-native token factory)

Zora (NFT and social tokens)

BaseMeme (meme token factory on Base)

Tip: Treat launchpad tools as research inputs for strategies that scout newly deployed tokens. Combine them with current risk reports and explicit source-health status before trading any newly discovered token — new launches are a common vector for honeypots and rug pulls.

---

Market data tools

Your Hub agent can request multi-source market data to inform EVM trading decisions. Availability depends on the configured providers, their current quotas, and local circuit/source-health state.

---

Social research (Neynar / Farcaster)

Where configured, your Hub agent can query Farcaster social data via the social tool family. This is relevant for EVM trading because many Base tokens are created by or discussed within the Farcaster community. Use social research as supporting evidence and preserve unavailable/degraded provider status when it cannot be fetched.

---

Simulation tools (Tenderly)

Before executing a complex EVM transaction, your Hub agent can simulate it using Tenderly:

Gas estimation is particularly useful for DeFi strategies involving multiple hops or complex contract interactions where gas costs can vary significantly.

---

Example trade flow: buying BRETT with 0.05 ETH

Here is what happens end-to-end when you ask an agent to buy 0.05 ETH of BRETT on Base:

1. Token resolution — The agent calls trading_evm_token_resolve to confirm BRETT's contract address on Base.
2. Pre-trade report — trading_evm_pretrade_report runs GoPlus and Honeypot checks on the BRETT contract in parallel.
3. Quote — trading_evm_quote fetches the 0x route, expected BRETT output, gas estimate, and price impact.
4. Policy check — The engine validates the trade against your max drawdown, daily loss limit, and position size settings.
5. Summary — The agent flow presents the quote, platform fee, slippage, and the GoPlus security summary.
6. Confirmation — You confirm the trade, or an eligible order proceeds through the authorized path when policy allows it.
7. Submission — trading_evm_swap is called with submit: true. The engine signs the transaction with your custodial EVM wallet and broadcasts it to Base.
8. On-chain verification — The engine monitors the submitted transaction until it is confirmed, failed, or marked for follow-up.
9. Order update — The order status reflects the lifecycle state, such as submitted, confirmed, filled, failed, or reconciliation-required. The Trading Dashboard and Trade History should show that state rather than treating submission as final execution.

---

Tips and warnings

Tip: Run a current pre-trade or risk report before buying a newly launched token on Base. Honeypot and provider checks are supporting evidence; missing, stale, or degraded evidence should block execution or require explicit review according to policy.

Tip: Use trading_evm_dex_pool_lookup to find the relevant liquidity pool before checking pool state. Pool addresses are needed for the state and events tools.

Tip: For time-sensitive Base transactions, use trading_simulation_evm_gas_estimate to estimate gas before submitting. Base gas prices are generally low, but complex multi-hop swaps can use significantly more gas than simple token transfers.

Warning: GoPlus and Honeypot checks analyze the contract at a point in time. A contract can be modified (if it is upgradeable/proxy) after the check. Always verify the is_proxy flag in the GoPlus result. If it is true, treat the security check as conditional.

Warning: EVM transactions broadcast to Base cannot be reversed. Once the engine submits the transaction, it will execute (or fail on-chain) within the gas price and nonce constraints. Confirm the quote and security report before proceeding.

---

Common issues

"No default EVM wallet configured" error. You have not yet created a custodial EVM wallet on Base, or no wallet is set as primary. Use the authorized Hub wallet flow to create or select a custodial EVM wallet.

"Insufficient funds" when placing an EVM trade. Your custodial Base wallet needs ETH to cover gas and the input token for the swap. Fund it by sending ETH and/or USDC to the wallet address shown on the Wallets page.

GoPlus reports "is_honeypot: true". Do not trade this token. Honeypot tokens are designed to let you buy but prevent you from selling. The pre-trade check will block execution by default. If you believe the result is a false positive, verify the token's sell behavior manually on a test network before proceeding.

Quote shows very high price impact (greater than 5%). The liquidity pool for this token is too shallow for your trade size. Reduce the trade amount, split the order into smaller trades over time, or wait for more liquidity to enter the pool.

Trade submitted but stuck at "submitted" for more than 5 minutes. The transaction may be stuck due to low gas price or Base network congestion. Check the transaction on BaseScan using the order ID in Trade History. If the transaction was not mined, it will eventually expire and the order will be marked as failed.

Token address not recognized by trading_evm_token_resolve. The contract may not exist on Base (chain ID 8453), or it may be too newly deployed to appear in the engine's lookup index. Double-check the contract address on BaseScan before trading.

---

Related pages

• Solana Trading — Trading on Solana via Jupiter aggregation
• Agent Wallet Management — Set up and review Hub agent wallets
• Rules and Runtime — Configure Hub agent rules and runtime state
• Hub Overview — Monitor active Hub agent operations
• MCP Integration — Access trading tools via the Model Context Protocol