You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A big selling point of ETH is the lack of need of approvals. Requiring all pairs be token-token means that everyone always has to do approvals when using Uniswap which increases user friction.
Solution - Native ETH Exchanges
Do what Uniswap v1 did and always have ETH as a base. In order to support token-token pairs (which I still argue are a bad idea in general as it bifurcates liquidity, but it seems I have lost that battle), you could have two Uniswap exchange contracts one for token-token (like you have now) and one for token-eth. The factory can create either token-eth or token-token exchange based on inputs (or function being called) and the UI can trivially aggregate these two sets of contracts into a single UI. This would allow you to not have the code complexity that comes with trying to do branching inside of the exchanges based on denominating token vs ETH. You could reduce code duplication by using inheritance such that most of the business logic is inside a base contract (all the mathing and whatnot) while the derived contract would just have implementation code for the send function and receive function.
Solution - ERC777 ETH Wrapper
ERC777 supports approval-free transfers by way of wrappedEth.transfer(uniswap, amount, callbackData) where callbackData contains details of the attempted trade. The exchange would then execute the trade as normal, with the exception of not using msg.sender anywhere and instead use the from provided in the tokensReceived callback.
The text was updated successfully, but these errors were encountered:
this is more of a router problem, also note that the router will include payable functions so that users can interact with WETH-ERC20 exchanges using ETH directly!
* add a currency entity
* revert test change, remove unnecessary `as any`
* remove unnecessary truthy assertions
* support currency amounts for input/output of trades
* support currency amounts for input/output of trades
* allow routes to encode if they end in ETH/WETH
* get the trade/route to support ether input/output
* router test
* add some todos
* working best trade exact in
* working best trade exact out
* remove only
* tests for exact in router methods
* complete the router tests
* add value as an output swap parameter
Problem
A big selling point of ETH is the lack of need of approvals. Requiring all pairs be token-token means that everyone always has to do approvals when using Uniswap which increases user friction.
Solution - Native ETH Exchanges
Do what Uniswap v1 did and always have ETH as a base. In order to support token-token pairs (which I still argue are a bad idea in general as it bifurcates liquidity, but it seems I have lost that battle), you could have two Uniswap exchange contracts one for token-token (like you have now) and one for token-eth. The factory can create either token-eth or token-token exchange based on inputs (or function being called) and the UI can trivially aggregate these two sets of contracts into a single UI. This would allow you to not have the code complexity that comes with trying to do branching inside of the exchanges based on denominating token vs ETH. You could reduce code duplication by using inheritance such that most of the business logic is inside a base contract (all the mathing and whatnot) while the derived contract would just have implementation code for the send function and receive function.
Solution - ERC777 ETH Wrapper
ERC777 supports approval-free transfers by way of
wrappedEth.transfer(uniswap, amount, callbackData)
wherecallbackData
contains details of the attempted trade. The exchange would then execute the trade as normal, with the exception of not usingmsg.sender
anywhere and instead use thefrom
provided in thetokensReceived
callback.The text was updated successfully, but these errors were encountered: