Non-Custodial Trading Bot: How It Works (and Why It Matters After FTX)

Why This Question Matters Now

For ten years, “automated crypto trading” meant signing up to 3Commas or Cryptohopper and pasting your Binance API keys into their dashboard. The model worked because exchanges were fast, deep, and seemingly safe. Then 2022 happened. FTX collapsed with $8 billion of customer funds frozen. Celsius and BlockFi followed. In 2024, Bybit suffered the largest exchange hack in history.

Each event reset the question every retail trader has to answer: do I trust this venue with my keys, my balance, and my withdrawal queue? For a growing fraction of users, the answer is no. They have moved to non-custodial trading — and the bots have followed them.

What “Non-Custodial” Actually Means

Custody is the right to move someone’s assets. A custodial system holds your funds in its own wallet and you ask it nicely to do things; a non-custodial system holds your funds in a wallet you control, and any action requires a signature from a key only you possess.

Most “non-custodial” claims are weaker than the term suggests. Some platforms hold a master key that can theoretically override your account. Others use multi-sigs where the platform is one of the signers. The real test is simple:

If the company running this bot disappeared overnight, would you still be able to withdraw 100% of your funds with no help from anyone?

For a properly built non-custodial bot the answer is yes. Your funds live in a smart contract whose owner key you generated yourself. The bot has a scoped permission to call one function on one contract — usually the DEX router. If the bot operator vanished, you would simply revoke the session (or ignore it) and your assets would still be in your Safe, untouched.

How a Non-Custodial Bot Is Built

Three components matter. Get any of them wrong and the “non-custodial” label is theatrical.

1. Smart Account (Safe)

The user’s funds live in a smart contract — typically a Safe (formerly Gnosis Safe), the most battle-tested smart account on Ethereum, securing tens of billions of dollars. The Safe has one owner: your externally-owned account (EOA), controlled by your MetaMask seed phrase. The bot is not an owner. The platform is not an owner. There is no admin key.

2. Module: ERC-7579 Smart Session

ERC-7579 is the modular smart account standard that turns a Safe into a programmable wallet. A Smart Session module attached to your Safe records, on-chain, exactly what the bot is allowed to do. The data structure is roughly:

• Validator: a contract that checks the bot’s signature on each transaction.
• Action policies: what contracts the bot can call (e.g., only Uniswap V3 SwapRouter02).
• Selector restrictions: which functions on those contracts (e.g., only `exactInputSingle`).
• Spending limits: per-token and per-tx caps.
• Expiry: a Unix timestamp after which the session is dead.

Read more about the standard in EIP-7579 and the Smart Sessions implementation by Rhinestone.

3. Bot Service

The bot itself is a backend service that holds a session signing key — a key that can only sign actions matching the policies above. It builds UserOps (ERC-4337 user operations), signs them, and submits them through a bundler. If the bot’s key is stolen, the attacker still cannot do anything outside the session’s limits — the Safe contract rejects unauthorized calls before they execute.

Smart Sessions: Scoped, Revocable, On-Chain

The unique property of a Smart Session is that the permissions are enforced by the blockchain, not by a server. A regular API key is enforced by Binance’s code. If Binance’s code has a bug, or an insider abuses access, the API key’s “read-only” promise can fail. A Smart Session, by contrast, is enforced by Ethereum consensus — the same mechanism that secures $400B of value across every smart contract.

This matters because retail trust does not extend to “the bot operator promises to be careful.” The whole point is to assume the operator could be malicious and design the system so it doesn’t matter. With a Smart Session, even a fully compromised bot service can only execute swaps inside the session’s limits.

Three properties make Smart Sessions practical:

1. Scoped. The session signs only specific functions on specific contracts. Anything outside that scope reverts on-chain.
2. Revocable. The user can call removeSession(...) on their Safe at any time. The session goes dead instantly. No grace period, no support ticket.
3. Time-bounded. Default expiry is typically 30–90 days. Auto-expiration ensures forgotten sessions die naturally.

What the Bot Cannot Do (And Why)

Specifically, with a properly configured Smart Session for trading, the bot cannot:

• Send tokens to any external address — the only allowed call is the DEX swap, whose recipient is hardcoded to the Safe itself.
• Withdraw funds from the Safe — there is no transfer function in the action policy.
• Add itself as a Safe owner — that requires owner approval (your MetaMask).
• Approve unlimited tokens to a malicious contract — the policy may pre-approve only the router, not arbitrary spenders.
• Execute trades after revocation — once the session is removed, signed UserOps fail validation.
• Touch funds on other chains or in other wallets — sessions are per-Safe.

The single thing the bot can do is execute swaps on Uniswap V3 inside your Safe, in tokens you whitelisted, up to amounts you set, until the expiry you chose. That is the whole authority. There is no override, no master key, no “admin can pause your withdrawals.”

Compared to API-Based CEX Bots

The functional difference looks small from a user’s seat — both bots execute trades while you sleep. The risk surfaces are different in kind, not degree.

Strategy bugs and contract exploits are real but low-probability for a properly audited stack. Operator-side risk is the dominant historical loss source for retail. Non-custodial designs eliminate it almost entirely.

Honest Tradeoffs

A non-custodial bot is not free of friction:

• Setup is heavier. Deploying a Safe and granting a session takes 10–15 minutes versus the 60 seconds of pasting an API key.
• Less leverage and fewer instruments. Most non-custodial bots cover spot DEX trading. Perpetuals, options, and high-leverage strategies live mostly on CEXes still.
• You pay gas. On L2 this is pennies; on Ethereum mainnet it can be meaningful for small trades.
• Self-custody responsibility. If you lose your MetaMask seed phrase, no one can recover your funds. There is no “forgot password” flow.
• Liquidity is DEX-bounded. For major pairs (ETH, BTC, USDC), Uniswap V3 has plenty. For obscure tokens, CEX liquidity is often deeper.

For most retail traders accumulating ETH, BTC, or stablecoins, none of these tradeoffs is meaningful. For perpetual scalpers chasing 100x leverage, a non-custodial bot is not the right tool.

Who Should Use a Non-Custodial Bot

The simplest filter: if your trading thesis includes any of the following, switch.

• You hold more than $1,000 of crypto — non-custodial removes counterparty risk.
• You believe the next exchange failure has not happened yet — exchange risk is a fat-tail event.
• You want long-horizon DCA without monthly stress about platform integrity.
• You live in a jurisdiction where exchange access is unstable (geo-blocks, KYC freezes).
• You already use a hardware wallet — you understand self-custody mental model.

If you are still trading $50 lots and learning the basics, a CEX with one-click bots may be more forgiving for now. The migration to non-custodial usually happens after the first real loss to a custody event — but the lesson is cheaper to learn before that.

How to Set One Up Without the Footguns

1. Use a hardware wallet for the owner key. Your Safe’s owner is the only party that can revoke or change permissions. Keep that key on a Ledger or Trezor, not in MetaMask alone.
2. Start on testnet. Sepolia is free. Deploy a Safe, grant a session, run a strategy, verify the bot does what it says. Most platforms — including DCA Bot — support full testnet flow on the free plan.
3. Read the action policy before signing. The session-grant transaction shows you exactly what the bot will be allowed to do. Verify the contract address (should be Uniswap V3 SwapRouter02 — 0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45 on mainnet) and the function selector matches what the docs claim.
4. Set tight per-token caps. Even though the bot cannot transfer out, tighter caps reduce the worst-case impact of strategy bugs (e.g., a misconfigured grid placing oversized orders).
5. Pick short expiries first. Default to 30 days. After a month of running smoothly, extend to 90.
6. Verify on a block explorer. Every trade the bot executes is a public on-chain transaction. Spot-check the first 5–10 against your strategy log.

Red Flags to Avoid

Not every product calling itself non-custodial deserves the label. Watch for these warning signs:

• “We hold your seed phrase encrypted.” Any product that touches your seed phrase is custodial in disguise.
• Multi-sig with the platform as a co-signer. If the platform is needed to authorize a withdrawal, you are not in control.
• Sessions without expiry. A bot session that lasts forever defeats the point. Always pick a finite expiry.
• Vague permissions. If you can’t see exactly which contract and which function the bot will call, do not grant.
• No revocation UI. Revocation must be one click and must happen entirely on-chain. If it requires emailing support, walk away.
• Closed-source policy contracts. The contracts enforcing the session must be verified on Etherscan. Black boxes are not security.