Skip to content

Instantly share code, notes, and snippets.

@Dexaran

Dexaran/dex223_dev_report_2025_april_may.md Secret

Last active June 2, 2025 22:22
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save Dexaran/d5716b2c9dbd3edfc579b1486153f481 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save Dexaran/d5716b2c9dbd3edfc579b1486153f481 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
dex223_dev_report_2025_april_may.md

Dex223 development report (April - May 2025)

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 in ERC-20 has caused over $100M in losses on Ethereum in 2023. Take a look at other Dex223 development reports.

Browse other Dex223 development reports here.

Dex223 core debugging & re-deployments

The first instance of Dex223 was deployed on Ethereum mainnet on March 31 2025: https://etherscan.io/tx/0x580a6ebbdb9eb4bd04e337ecf3e58bc145aaace4cca00e6f3064e9537b10cc00

After the completion of the security audit (you can find audit report here) we've applied a set of changes to the contracts. However, the production implementation highlighted USDT compatibility issues which were not identified during the testing stage and during the audit.

Not only USDT is not technically compatible with the ERC-20 standard specification, it also doesn't allow manipulating the allowance parameter if you already have a non-zero amount of approved tokens. This detail would impact the workflow of Dex223 USDT pools since these pools need to issue and re-issue approvals to the Token Converter in order to auto-convert ERC-20 USDT to ERC-223 version on demand.

We had two options here: (1) handle this on the UI side (by hardcoding an exception for USDT swaps which would cause users to convert ERC-20 USDT to ERC-223 version in a separate transaction should they request it) or (2) implement a patch for the USDT and re-submit the contracts for audit update.

It was decided to choose the second option, since it would reduce the gas costs for end users compared to the first option.

The fix was applied in the following commits:

The audit report on Beosin's resources also includes the updated contracts now.

After that fix was applied the whole contracts system was re-deployed at the following addresses:

Ethereum Mainnet deployment v2:

  • Factory 0x6228e33cea2a9bdfb7dfe09087841cb56f683f04

  • Pool Lib 0x1bc27faa75002e1f034e57c9e62236c2e0f7ed16

  • ⚠ Bad NFPM 0xedd183a3b4da4dbd210cd51d9ec83bf11c37fc0e (subsequently replaced with 0xca666abfdf2d31a3f4efff8ced7c6504389e51ba)

  • ⚠ Bad Router 0x6e628ea65ff39755d6bb7d002353694e6bd5abbb (subsequently replaced with 0xBE65a8dabc45d394E40B81977485096F4ee17558)

  • Auto-Listing Registry 0x105f43a70afced0493545d04c1d5687df4b3f48f

  • Core Auto-listing 0xf851ffe03478f0bfebd4337287f315350cc311c2

  • Free Auto-listing 0x0dc218cf5b88dd7add4a0d1b7ba4343884bad6df

Further testing highlighted more problems with those "bad" peripherial contracts (Router and NFPM) which were replaced as the result. The NFPM contract contained an internal variable issue tied to the compiler version mismatch and made it unable to properly compute pool addresses after the internal logic of how these pools work with USDT was applied. This bug was fixed at this commit: https://github.com/EthereumCommonwealth/Dex223-contracts/commit/c0355d4495cf432a7c32dca868ceef4cd36e529a

The NFPM was replaced with a functional one: 0xca666abfdf2d31a3f4efff8ced7c6504389e51ba

The Swap Router was replaced by this one: 0xBE65a8dabc45d394E40B81977485096F4ee17558

Another critical UI workflow issue was identified at the public testing stage by a community member. In this transaction a user deposited D223 tokens to the NonfungiblePositionManager smart-contract to provide liquidity for ETH-D223 pair: https://etherscan.io/tx/0x37ff0f8c7dff45ba450cf14aa1acb42c001e3f835cd9d0346b78957b4300f1b9

However the tokens became unclaimable due to an improperly issued claim request that specified the NonfungiblePositionManager as the recipient (technically the tokens were "claimed" but it happened that the contract itself became the owner of the funds). These tokens currently remain on the NFPM contracts balance and there is no way to extract them. We can only refund this operation manually. This problem was fixed https://github.com/EthereumCommonwealth/Dex223-UI/commit/612623d0a0ecb9482fff682ccf2144e148676da7

During the process of fixing the unclaimable tokens issue it was decided that it is necessary to update the workflow of claiming fees for token-native_currency pools. In UniswapV3 this process involves sweepToken(...) function which was removed from Dex223 Swap Router after the audit for security reasons since we consider reentrancy the main danger area of our system. This actually means that in the current system the process of claiming fees would involve one extra client-side transaction to "unwrap" the claimed native currency. This is a temporary measure and we would like to update the logic of the Swap Router in the future to streamline the process but for now we're sticking with the safest option.

This covers the most important findings that were identified during the public testing stage and forced us to delay the official launch and replace some parts of the system completely by re-deploying the contracts.

A working bug reports list can be found here: https://docs.google.com/spreadsheets/d/1b-RFj6oF32FXUyBD1dObT1UOJrNfpj2hL_iLoVXaxGg/edit?usp=sharing

Special Thanks to CallistoDAO members and our community members who took part in the public testing of the platform!

Dex223 public launch

All of the reported issues indicated in the bug reports document were fixed. Known issues mentioned in the previous development report were fixed as well.

There is the last UI-side issue related to improperly set price range boundaries when providing liquidity outside of the current range.

We will re-deploy the contracts once again to set the most optimal compiler parameters to improve the gas efficiency and after this version of contracts would be verified on Etherscan we will consider it to be final.

Margin module update

The implementation of Margin Module smart-contracts is completed. We consider this version to be a working prototype:

The margin module smart-contracts are deployed on Sepolia Testnet and we are starting the contracts testing.

The margin trading module of Dex223 consists of four main parts: (1) smart-contracts, (2) UI, (3) data relay that pulls data from the chain and provides it for the UI, (4) liquidation script.

The "liquidation script" is a tricky one here. A proper Dex can not implement a fully functional liquidation engine in it's smart-contracts while staying truly decentralized. In Dex223 we are solving this problem by abstracting away the liquidation engine altogether and replacing it with a system of incentives that would encourage third parties to call "liquidations" on those positions which don't have enough funds on their balance. This is similar to how miners are incentivised to solve computation-intensive problems in Proof-of-Work systems by transaction fees and block rewards except in our case the "liquidators" are actually rewarded for manually updating the contracts' state by telling it that some positions no longer meet their funding criteria.

The liquidation script is a program that could constantly monitor the state of positions and prices in Dex223 pools. It should be able to decide when some position meets it's liquidation criteria and if it is "profitable" to liquidate it (i.e. the liquidation reward is higher than the gas fee that would be paid for sending this transaction) then it should be able to send the liquidation transaction.

We intend this system to be open for third parties and we encourage others to run their liquidation scripts that would help our system to diversify risks of not processing liquidations in time. We will run one instance of liquidations script ourselves in order to ensure the initial system's operability.

There is the current state of the parts of the Margin Trading Module at the current stage:

  • Smart-contracts: Completed / Working prototype is deployed and is being tested
  • Liquidations script: We have a prototype but it requires additional modifications and it's not production ready
  • UI: Figma templates are finished / Implementation is in progress
  • Data Relay: In development

Revenue Contracts

Since we are finishing the core platform deployment on Ethereum Mainnet we are now starting the implementation of the revenue system. We expect to have a working prototype within June 2025.

UI updates

Margin Trading UI was completed. There were minor changes, adjustments and bug fixes in the Core platform UI mostly related to the modifications of the workflow related to the fixes applied to the contracts and their workflow such as adding new transactions for fee claiming or displaying new states.

Supplemental UI features were designed: auto-listing contracts customization and management, revenue UI.

Full copies of our Figma are available here:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment