DEX–Arbitrum Vault: operation and security
The CoinRobot.AI community trading robot can trade on decentralized exchanges (DEXs) on the Arbitrum network. It uses dedicated, approved routers and a user-owned Vault smart contract designed to keep trading capital under clearly limited permissions. This article explains how that integration works, which address serves which purpose, and what its security boundaries mean in practice.
Read the complete CoinRobot trading flow for the common route from market data and strategy decisions to execution and balance monitoring.
In one minute: two addresses, two separate purposes
In the DEX–Arbitrum integration, every user deploys an individual Vault smart-contract instance from their own wallet. Trading capital remains in the Vault. CoinRobot's separate bot EOA may only execute trades or initiate returning all assets to the owner. Only the owner can withdraw to an arbitrary recipient.
Balance and network-fee information
Check the live balance in the Dashboard: open Dashboard and use Open position balances by connector. Select this Connector and load the full balance to see current assets and the part used by the robot in open positions.
Fees are handled by the robot: Arbitrum transaction fees are paid in ETH. The robot monitors its fee asset and, when necessary and feasible, can buy ETH from available USDC. Keep enough USDC available and monitor the notification email; an unavailable route or unsuccessful purchase can still prevent execution.
Terms and network details
- Arbitrum One
- An Ethereum Layer 2 network with chain ID
42161. Its faster confirmations and typically lower gas costs are well suited to DEX swaps while building on Ethereum's security model. Arbitrum alone does not eliminate sandwich/MEV or other abuse; router quotes, slippage limits, and Vault checks work together to reduce poor-execution risk. - USDC on Arbitrum
- The default stablecoin for trading capital and accounting. Official contract address:
0xaf88d065e77c8cc2239327c5edb3a432268e5831(6 decimals). Always verify both network and address before transferring. - Vault
- Your deployed smart contract that holds capital and permits only constrained swap and withdrawal operations.
- Bot EOA
- CoinRobot's technical wallet that signs authorized trades and separately holds execution-fee funding.
Your integration addresses
0x0f239418a54268f892f0779Ab338bA1675BaFa67This shared fallback address is shown only as a contract example. Do not send funds to it. Log in and deploy your own DEX Connector Vault before funding.
Code and contract on Arbiscan · Read Contract · Write Contract
Log in to view your personal bot address.This technical wallet lets CoinRobot trade the assets held in the Vault. Gas and the execution funding indicated by the UI are consumed here; send ETH for network fees as instructed by the interface.
Why does the Vault exist?
The Vault is an on-chain custody and authorization boundary on Arbitrum. The wallet signing deployment becomes the immutable owner. It lets the robot swap between narrowly permitted tokens through approved routers without receiving the private key or general control of the user's own wallet.
“Safe” has a precise meaning here: contract permissions constrain what the bot can do. It is not a promise against market losses, smart-contract bugs, malicious or defective tokens or routers, RPC/frontend failures, or compromised keys.
Why is there a separate Bot Wallet?
Only the owner and its designated bot may automate trades with Vault capital. The separate wallet isolates execution and fee funding from the user's own wallet, so CoinRobot never needs the owner's private key. The bot cannot freely access Vault assets or choose an arbitrary withdrawal recipient; even an aggregate withdrawal initiated by it always goes to the immutable owner. Fee funds on the bot address are outside the Vault, so keep only the required amount there.
End-to-end flow in the user interface
- Prepare a wallet: install MetaMask or another EVM wallet, select Arbitrum One (
42161), and hold a small amount of ETH for deployment and owner-initiated gas. - Create the Connector: after login, open Connectors, select DEX Arbitrum Vault, and start a new Connector. CoinRobot assigns your separate bot address.
- Deploy: connect the wallet, verify network and bot address, approve deployment in the wallet popup, and wait for confirmation. The signing address becomes immutable owner.
- Fund the right address: supported trading assets, typically USDC, go to the Vault. ETH requested for gas/execution funding goes to the bot.
- Start a Plan: in Plans select this Connector, configure strategy and amount, review the settings, and start it. Trades execute inside the Vault.
- Withdraw: stop the active Plan and choose withdrawal for this Connector. Normally CoinRobot's bot wallet signs and submits
withdrawAll, so no MetaMask prompt or owner signature is needed; the contract can send the proceeds only to the immutable owner. If the bot address lacks sufficient gas, the UI requests the owner wallet and signature as a fallback. The owner may also use Arbiscan Write Contract directly.
Owner walletfee funding →bot EOAtrade call →Vaultwithdrawal → owner
Permission model
| Operation | Owner | Bot EOA | Security boundary |
|---|---|---|---|
| Swap | Yes | Yes | Allowlisted tokens, configured router, spend and minimum-output checks. |
| Return all assets | Yes | May initiate | Recipient is always the immutable owner. |
| Send one token or native ETH to any recipient | Yes | No | onlyOwner. |
| Change bot, routers, or token list | Yes | No | onlyOwner. |
Important: ownership cannot change and there is no ownership-transfer or administrator method. CoinRobot cannot recover a lost owner key. Owner authority is intentionally powerful: it can change routers and the bot, manage tokens, and withdraw any token or native ETH to any address.
Every public function and state reader
The source corresponding to the executable Vault bytecode is verified on Arbiscan, public, and open for anyone to inspect. Open the source on Arbiscan. The cards below explain the functions in that code.
constructor(_botAddress, _initialTokens)
Makes the deployer the immutable owner, sets the bot, and installs initial 1inch, 0x, and KyberSwap router addresses. It attempts each initial token and skips zero addresses, non-contracts, duplicates, or contracts without a valid balanceOf, emitting an event. The contract itself permits a zero bot at construction, so the deployment client must supply it correctly.
receive()
Accepts native ETH. Current trade logic handles ERC-20 tokens, so native ETH held by the Vault is not a swap input; the owner can recover it with withdrawNative or the aggregate withdrawal.
about()
A pure version identifier returning CoinRobot.AI ERC20 Trading Vault v1.6.
trade(router, tokenIn, tokenOut, amountIn, minAmountOut, data)
Callable only by bot or owner and protected against reentrancy. It rejects zero amounts, zero/equal token addresses, non-allowlisted tokens, and any target other than the three current routers. It snapshots balances, approves exactly amountIn, invokes the router using supplied calldata, clears allowance, and requires spend no greater than amountIn and receipt of at least minAmountOut. Any failure reverts the entire transaction, including approval. The Vault does not decode data; the trust boundary therefore includes the approved router implementation.
withdrawAll()
Bot or owner may call it; it is reentrancy-protected. It iterates the current allowlist and attempts to transfer every balance to owner. A defective token is skipped and logged instead of blocking the remaining tokens. It then sends all native ETH to owner. The bot cannot select a recipient. A token previously removed from the allowlist is no longer visited and must be recovered by owner through withdrawToken.
withdrawToken(token, to, amount)
Owner only. Sends a positive amount of any nonzero token—including one not allowlisted—to any nonzero recipient. Its safe wrapper supports both boolean-returning and older no-return ERC-20 behavior and reverts on failure.
withdrawNative(to, amount)
Owner only. Sends a positive native ETH amount to a nonzero recipient if the balance is sufficient; failure by the recipient reverts.
updateRouters(oneinch, zeroex, kyberswap)
Owner only. Replaces all three router addresses together; none may be zero. It does not verify contract bytecode or protocol identity, so validating replacements is the owner's responsibility. An event records the change.
addToken(token) and removeToken(token)
Owner-only allowlist management. Addition requires bytecode and a working balanceOf; zero and duplicate addresses are rejected. Removal compacts the array by swap-and-pop, so ordering can change. Removing a token neither transfers nor destroys its balance; it only disables trading and excludes it from the aggregate-withdrawal loop.
setBotAddress(newBot)
Owner only. Replaces the authorized trading bot and logs old and new values. A zero address is accepted, effectively disabling automated bot access while owner trading remains available.
Readers
getAllowedTokens() returns the complete list and allowedTokensLength() its size. Solidity-generated getters expose owner, botAddress, oneinchRouter, zeroexRouter, kyberswapRouter, isAllowedToken(address), and allowedTokens(index). Anyone can verify these without logging in through Arbiscan Read Contract.
Internal safeguards and audit trail
SafeERC20 requires bytecode, propagates call failure, and—when return data exists—requires true. ReentrancyGuard prevents nested execution of trade and withdrawAll. Internal token registration keeps mapping, index, and array synchronized; tolerant balance/transfer helpers prevent one defective token from blocking the whole aggregate withdrawal.
TokenStatusUpdated, TokenAddSkipped, BotAddressUpdated, TradeExecuted, FundsWithdrawn, TokenWithdrawSkipped, and RouterAddressesUpdated create an on-chain audit trail. Events assist reconstruction but should be checked alongside current state and token Transfer logs.
Operational security checklist
- Use Arbitrum and your addresses shown in the Connector; send a small test amount first.
- Send trading tokens to the Vault and only requested fee funding to the bot EOA. Assets on the bot EOA do not receive Vault withdrawal protections.
- Verify owner, bot, routers, and token allowlist through Arbiscan Read Contract.
- Never disclose the owner seed phrase or private key. CoinRobot does not need it.
- In an emergency stop the Plan, then call
withdrawAllor a targeted withdrawal from the owner wallet. Unknown tokens require targeted withdrawal. - The owner wallet also needs native ETH to pay gas for owner-initiated transactions.
This article describes the repository's v1.6 contract. On-chain address, state, and transaction data remain the final publicly verifiable record.