https://github.com/Uniswap/v3-periphery/blob/main/contracts/base/SelfPermit.sol#L4-L5 The original Uniswap V3 contracts were written quite some time ago and they require solidity compiler version to be strictly 0.7.6. However, as some contracts relied on imports from OpenZeppelin's github repo (which is now upgraded) if you would just take the code from https://github.com/Uniswap/v3-periphery repo and try to compile it with Remix - it would just fail.
Restoring compatibility turned in a cumbersome task of searching for the codes compatible with the version required by Uniswap at the time of its creation. This was done and there is the code that does actually compile with Remix as of today:
https://github.com/Dexaran/UniswapV3-periphery-updated/tree/main/contracts
Conclusion: Do not use imports relying on github repos in production! Respect third party developers who may be browsing the code years after it was deployed.
Uniswap V3 is composed of multiple smart-contracts:
- Factory - this one creates Pools when someone wants to add a new pair to Uniswap.
- Pools - each trading pair in a Uniswap is a Pool contract. Liquidity providers deposit liquidity to Pool contracts as well so this one is actually storing the tokens. However you can't trade or add liquidity to the pool contract directly and instead you need to use a special "intermediary" contract <== this is a limitation related to the ERC-20 standard and we can remove it with ERC-223
- NonFungiblePositionManager - intermediary contract responsible for liquidity providing. When a user wants to add liquidity, change liquidity amount or collect fees - this one is called. Also it mints NFTs (each position is an NFT).
- Router - intermediary contract responsible for trading operations. When a user wants to swap something - this one is called.
In Uniswap v2 docs there is a reasoning provided for why the intermediary contracts are needed: https://docs.uniswap.org/contracts/v2/concepts/core-concepts/swaps#sending-tokens
It should be noted that with ERC-223 it would be possible to make a deposit and trigger a swap function call with one transaction.
A normal ERC-20 swap of X token A for Y token B on Uniswap would look as follows:
- A user
approvesRouter contract to take X token A << this is a transaction - The user calls Router contract telling it "take my tokens and swap for B"
- Router pulls X token A from the user and calls the Pool contract << transfer of a token
- Pool contract initiates the swap and calls the Router back thus telling it to pay token A
- Router transfers token A to the Pool << transfer of a token
- Pool delivers token B to the user << transfer of a token
So, it takes 1 approval transaction and 3 internal token transfers to complete a swap of ERC-20 tokens.
If token A would be ERC-223 then the swap would look differently:
- A user sends ERC-223 token A to the Pool contract thus telling it to initiate a swap for token B (using
_dataof ERC-223 transfer()) - Pool executes the swap and delivers token B to the user
It is possible to eliminate one extra transaction (approvals are not needed for ERC-223) and one internal transfer of a token with ERC-223 thus making direct swaps cheaper. It should be noted that it is not required for a token B to be ERC-223 compatible in this scenario.
Multihop swaps however will still rely on the Router contract so ERC-223 support for the Router is still required.
This is one of the most important features that would establish a path for upgrading tokens. With EIP-7417 existing ERC-20 tokens would become convertable to ERC-223 i.e. if there was a ERC-20 USDT token then there will be a new ERC-223 USDT token and it will be exchangeable for ERC-20 USDT at 1:1 ratio in a similar way to how ether can be "wrapped" to WETH. The problem here is that from DEX's point of view these are just two different tokens.
I'm currently working on updating the Pool contracts logic that would allow "merging" liquidity provided in tokens of different standards without resorting to wrapping and unwrapping them.
A user would be given an option to choose the "preferable standard" upon making a swap. If both versions of the token are stored in the Pool contract then it will try to deliver the token of the preferred standard to the user. If there is not enough liquidity provided in the desired standard token then it's other version will be "unwrapped" and delivered to the user. This method of unwrapping on demand would ensure higher efficiency with enough liquidity provided in tokens of both standards.
Contracts implementation schedule is as follows:
- (done) Updating libraries
- (done) Finalizing ERC-223 workflow concepts
- (in progress) Basic support of ERC-223 in Router and NonfungiblePositionManager: swaps and adding liquidity with ERC-223 tokens without approval() transaction
- (in progress) Auto-listing contracts
- Routerless single swap implementation in a Pool contract
- Merged ERC-20 & ERC-223 liquidity
- Lending & Margin trading implementation
Initially we will rely on existing Uniswap V3 contracts on Sepolia and the first versions of the demo UI will work with them. Auto-listing contracts can also be tested against Uniswap V3 as they only feed data to the UI. After the basic features of Uniswap and auto-listing contracts will be supported we will proceed to the native support of ERC-223 interaction patterns.
You can browse the state of the UI templates here: https://www.figma.com/file/WPkdnWK0kdKjlUr0Z10CJa/%F0%9F%94%84-DEX223-Exchange-%F0%9F%94%84-(Copy)?type=design&node-id=2460%3A62488&mode=design&t=VGoerk5XW8ygbD9j-1
We managed to finalize the design of the most important pages (Swaps, Liquidity, Tokenlists). We are still working on margin trading, lending/borrowing and token management pages so these available in the Figma currently will likely change.
We will start the implementation of the Liquidity page first. Then swap and token lists will be added. We have to re-implement a significant part of what Uniswap has right now in order to start implementing Dex223 unique features.
We expect to deploy a working version on Sepolia Testnet mid April. This version will support:
- Adding/removing liquidity, collecting fees
- Swaps
- Auto-listing contracts. Everyone will be able to "auto-list" their test tokens on Dex223 test UI through one of the core auto-listing contracts. At the same time everyone will be allowed to create their custom listing contracts and just import them in their UI or share with other users.
If you have any wishes or feature requests feel free to submit them in the comments to thig github gist or via our telegram channel.
We've started the process of establishing a legal entity for Dex223. This is a requirement to get D223 token listed on centralized exchanges. We will probably proceed to listings earlier than we initially expected.