Skip to content

Instantly share code, notes, and snippets.

@Dexaran

Dexaran/dex223_dev_report_2025_august_september.md Secret

Last active October 7, 2025 00:41
Show Gist options
  • Save Dexaran/5f403cd65775dc45b123cd5816837cf0 to your computer and use it in GitHub Desktop.
Save Dexaran/5f403cd65775dc45b123cd5816837cf0 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
dex223_dev_report_2025_august_september.md

Dex223 development report (August - September 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 platform

There were no changes to the core platform smart-contracts implemented during this months. The testing team discovered a number of UX-related problems that could entail potential problems for anyone who would use the platform however. These problems were mostly related to the workflow of ERC-223 tokens.

1. Core platform update: ERC-223 token creation page

A lot of problems emerged with the creation of ERC-223 pools when users were deploying their customly built ERC-223 original tokens. Initially the DEX was designed to work with existing ERC-20 tokens and their ERC-223 wrappers created via Token Converter.

It proved to be very problematic to explain the process of creating a ERC-223 token that can interact with Dex223 correctly since the process of token standard recognition is clunky and requires a number of specific features to be implemented in the ERC-223 original token. Token standard recognition requirements are not part of the EIP-223 because the EIP process did not allow these to be part of the standard documentation at the moment of its creation and now since the EIP is already finalized there is no way to add any new relevant information anymore.

As the result it was decided to build a separate page that would allow users to create proper ERC-223 tokens easily.

The ERC-223 token creation page is currently available on the testnet version of the DEX: https://test-app.dex223.io/en/create-token

DEX223_new_token

The ERC-223 Token Deployer contract is now live on Ethereum mainnet: https://github.com/EthereumCommonwealth/Dex223-contracts/commit/8e76fad7dfa8b4902614f91f5e7ba972c910b4c7

https://etherscan.io/address/0xe3391c70A6b71bC26D6F77437590306006aD0ddb#code

2. Core platform fix: ERC-223 pool creation

Dex223 is optimized to work with existing ERC-20 tokens and their versions created by the Token Converter. Therefore the standard recognition method assumes that the ERC-20 version of a token must exist at any time (which is true for most existing tokens anyways). This doesn't work for the deployed ERC-223 original tokens however.

It was decided to auto-deploy ERC-20 wrappers for any ERC-223 original token at the moment of a pool creation.

3. Core platform: known problem with approve & transferFrom pattern in ERC-223 tokens

The current implementation of the NonfungiblePositionManager contract (which handles liquidity providing and fees claiming) moves ERC-223 tokens with the transferFrom(..) function. This function is not a part of ERC-223 standard and therefore is optional for a purely ERC-223 token.

It must be mentioned that the approve & transferFrom pattern is a bad feature to have in a token as it was described in this article.

ERC-223 token wrappers created by the Token Converter however do have the approve & transferFrom functions for backwards compatibility reasons. Since Dex223 is designed to work primarily with wrapper-versions of tokens it was assumed that its safer to utilize this transferring method and therefore its used in PeripheryPayments contract: https://github.com/EthereumCommonwealth/Dex223-contracts/blob/main/contracts/dex-periphery/base/PeripheryPayments.sol#L132

This would allow non-ERC-223-compatible multisigs to provide liquidity and claim fees from Dex223.

The current NonFungiblePositionManager would fail to provide liquidity to Dex223 pools if the ERC-223 token didn't have the transferFrom function implemented.

This is another reason to implement a ERC-223 creation page and suggest users to create their tokens there instead of deploying a cusom one.

We will deploy a dedicated ERC-223 NFPM contract that wouldn't require this functions to work with purely ERC-223 tokens in the future.

4. Auto-listing contracts were simplified to allow for manual configuration

The workflow of auto-listing contracts was modified so that it would allow to list a token without creating a pool on Dex223 to define a list of pre-listed tokens or manually list a token for the owner of the contract (which was previously not possible due to the requirement to link a Pool in the listing transaction).

Testnet auto-listing contracts are updated: https://github.com/EthereumCommonwealth/Dex223-contracts/tree/main?tab=readme-ov-file#sepolia-testnet-deployment-quoteswap-supported

The auto-listing cocntracts on Ethereum mainnet must be re-deployed and re-configured.

Margin Module update

Margin Module passed a series of tests that exposed flaws in the method of contract state inspection. The liquidation script struggled to predict the amount of time required for a position to get liquidated based on accrued interest if there would be absolutely no changes to the token prices involved.

As the result it was decided to implement a specific function that would expose this information calculated within the contracts internal logic with an additional introspection function subjectToLiquidationExtended(..) https://github.com/EthereumCommonwealth/Dex223-contracts/blob/12cee2be17496f9b0a669fa93ed1bde5385d0bed/contracts/dex-core/Dex223MarginModule.sol#L2926-L2959

The latest version of the liquidation script is available here: https://github.com/EthereumCommonwealth/Dex223-margin-liquidation-script/tree/9dd970c4cd85792c38c231ef4e22bf040bab62fc

The last testing suite of margin module exposed no flaws neither in smart-contracts logic nor in the liquidation scripts (except for the aforementioned inconsistency in liquidation time prediction based on accrued interest which is already solved).

The last pending step in the margin module development cycle is the stress testing. The biggest problems with most centralized exchanges occur when the markets experience significant volatility. In this case cascading liquidations can mess the workflow of liquidation engines. The best example of this problem is a flash-crash of XRP on 13th Feb 2020 on BitMEX: https://news.bitcoin.com/xrp-plummets-56/

The specifics of BitMEX's liquidation engine caused it to executed liquidations in such an order that triggered liquidations of other positions and this pushed the price to extreme levels and its uncertain if this would naturally occur if these trades would be manually executed one-by-one. In order to ensure that Dex223 doesn't suffer from the same problems or otherwise possible technical issues that can cause the liquidation script to "miss" some liquidations in a cascade we will artificially construct a scenario where dozens of positions are placed one just above another so that the liquidation of each position number X would trigger the subsequent liquidation of position X-1.

If the stress test of the Margin Module would be passed successfully then the last step would be a security audit and the Margin Module would be considered completed.

Dex223 bugbounty program

We've handled a round of community bugbounty during this months: https://github.com/rroland10/dex223-bug-bounty/tree/main

So far there were 4 issues reported. One of them exposed a potential security improvement related to iframe usage in the platform frontend (here is the report: rroland10/dex223-bug-bounty#3). The reward was paid out to @nathanogaga118 https://etherscan.io/tx/0x611a282edf5ddd41632b91833df517a822c96b3b4602301018b925dc2c870f0b

It must be mentioned that the bugbounty is still active and everyone is welcome to contribute. This time it includes UI-related issues, not only the smart-contracts.

Fiat onramp implementation is completed

It was mentioned in the previous reports that we were working on fiat onramp. This task was suspended for quite a while but we are happy to announce that the implementation is completed and fiat onramp is live on https://exchange.dex223.io/en?fiatExchange=true

It is possible to buy crypto via Dex223 UI with credit cards now.

Revenue contract is completed

The revenue contract source codes were committed to the dex-periphery repo: https://github.com/EthereumCommonwealth/Dex223-contracts/blob/main/contracts/dex-periphery/Revenue.sol

The UI implementation is still in progress. There is no ready-to-use instance configured to work with the test UI yet but this component of the project is expected to be completed during the next month.

The revenue contract implements a 3-day unstaking delay now (which was not announced initially and it was not planned from the very beginning). I'll explain the reasons for this last-minute change in a separate article.

Governance multisig is completed

We've deployed a multisig that would store D223 tokens on Ethereum chain: https://etherscan.io/address/0xf4986e03848887f31c6ec80b24e182316f4af656#code

Currently most of the team's tokens is held on an externally owned address. We are planning to move the teams tokens to the multisig in the near future so that to avoid uncertainty among the token holders.

ApeChain deployment

Dex223 and ERC-223 token standard are intended to be multi-chain projects. We are going to deploy the platform on another network and ApeChain (chain id = 33139) was chosen as a good trial target.

We are going to announce the deployment in the coming weeks, make a D223 tokens snapshot, airdrop the tokens on the original D223(ETH-chain) holders. The team is currently workin on an airdrops page that will serve the purpose of defining the roadmap of future deployments.

UI updates

As always, there are Figma templates of the UI:

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