This article is a development report for the Dex223 decentralized exchange.
We’re building an exchange to speed up the adoption of the ERC-223 token standard. ERC-223 was created to address a security problem in the older ERC-20 standard. The security issue of ERC-20 has caused over $100M in losses on Ethereum. Take a look at other Dex223 development reports.
Browse other Dex223 development reports here.
In preparation for the launch it was decided to place 15K USDT and 15K USDC in a USDT-USDC liquidity pool and these funds were acquired on a Dex223 management wallet.
On Feb 13 2026 13906 USDT were drained from the wallet which held leftover funds: https://etherscan.io/tx/0x54bb31a5a1f5cb4d47f89d11d55c5e64e0de7b06956ba7c21d2062950357ccd5
The accident was investigated and we identified a vulnerability in the Router contract which was fixed in this commit: https://github.com/EthereumCommonwealth/Dex223-contracts/commit/ea41c72fd674e5710ea6f4ede0869f215509b8cd
The Router contrat in the current Dex223 contracts system was replaced with a new one.
I was able to reproduce the attack on Sepolia testnet: https://sepolia.etherscan.io/tx/0x935ab10ca68d7a6826610493363d06a45d2653c4e113642d9910f0c180ede39f
- Attacker (Sepolia): 0xfC029Cf6cE231432eca21b99De53bcAF1E4D037B
- Router (Sepolia): 0x99504DbaA0F9368E9341C15F67377D55ED4AC690
The problem with the Dex223 Router was related to a change that was introduced to make ERC-223 swaps executable in one transaction. In Ethereum there is a special msg.sender variable which identifies who called the contract. The problem here is that when a user is trying to swap ERC-20 tokens - the user calls the Router contract telling it "You have an approval, take my tokens and do the swap" so msg.sender = user. ERC-223 tokens work differently. The user is telling the token to make a transaction and encode the swap so the token contract is telling the Router that some user initiated the swap and also wants the tokens to be swapped. From the Routers point of view msg.sender = token.
In order to automate this workflow we have adjustable sender mechanic in place. Since Router always tries to make the initiator of the token transfer to pay for the swap - it needs to know who to charge.
So, with adjustable sender the Router is trying to charge the sender of the transaction if its a ERC-20 swap or it is trying to charge whoever the ERC-223 token tells it when its a ERC-223 swap: https://github.com/EthereumCommonwealth/Dex223-contracts/blob/51c998ce233b3437fc5c6ce0bd831c6707a8e1bb/contracts/dex-periphery/SwapRouter.sol#L320
The main problem that allowed the attack to happen was that the Router trusted ERC-223 tokens blindly assuming that it always provides the correct address of the token sender.
So the attacker architected a call which made Router record management address (which held the funds) as a token sender. Then the attacker asked the Router to perform a swap which management address would pay for. Therefore the attacker performed the swap but management address paid for it.
On Sepolia I reproduced exactly the same problem:
- We ask the Router for a token swap: 200 XE tokens for some HE tokens
- XE tokens are charged from 0x222E674F...08426b482 to the Pool
- HE tokens are delivered from the Pool to 0xfC029Cf6...F1E4D037B (our attack aaddress on Sepolia)
- 0x222E674F...08426b482 paid for the swap that 0xfC029Cf6... initiated.
Router contract runs additional checks and does not accept information about who is the transaction sender from any token which is not being swapped. If a user intents to swap USDT then the Router would only accept information from the USDT (or its ERC-223 version) within the scope of this transaction.
I would like to thank the attacker for exposing the vulnerability before the platform launch. Consider 13,900 USDT your bugbounty reward.
- The root of the problem is still the design of ERC-20 token's approval mechanic. The Router was tricked into thinking that the sender is a ERC-223 token but it had to pull funds via
transferFrom. If USDT would be a ERC-223 token - that wouldn't happen. - Diversification works better than trusting security audits. The management wallet never held a significant amount of USDT / USDC at the same time and since the funds were properly distributed between different wallets it wasnt possible for the attacker to pull a significant share of them.
- The platform needed another security reviews pass.
Dex223 contracts passed another security review but we were not able to identify any significant problems.
This time we also tried a few LLMs as a security analysis tool. My verdict is that LLMs are still far from reliable when security is concerned.
Out of all the LLM-generated reports none were able to identify the problem in the old Router which allowed the attacker to drain funds. They can find minor problems like leftover artifacts and outdated comments as well as suggest structural optimizations which are sometimes useful.
You can find a few LLM-generated reports under Dex-223-contracts pull requests here: https://github.com/EthereumCommonwealth/Dex223-contracts/pulls
Initial implementation of a revenue contract is completed.
Referral program is currently being developed by Blockz hub (former EOS Support).
We are planning to store D223 tokens and delegate all the platform-governing features (emergency functions only) to the founders multisig which will lock the unallocated D223 tokens. This is not currently deployed and will be described in the next report.
Currently the unallocated D223 tokens are stored in an externally owned address. I am strictly against the use of account abstracted addresses for critical resources.
We initially planned to launch Dex223 on EVM-compatible chians which don't have Uniswap or any other major DEX in place. The airdrops page is currently deployed to track the process.
However, most of these chains have literally no user activity and the vast majority of the on-chain transactions are just fake (or someone testing).
We will accept suggestions related to which chains could be targeted for future deployments. These suggestions can be submitted to our official telegram channel or the comment thread of this github gist.
Unfortunately the planned activities were interrupted by a security investigations during the previous month but right now spreading the word about the ERC-223 standard and Dex223 is our priority again.