“Uniswap is a protocol for automated token exchange on Ethereum.”. In fact it is a form of decentralized exchange implemented with Ethereum contracts. It provides an ability to exchange ETH on ERC20 tokens and vice versa. And if ETH is used as a common pair for for all tokens exchange so it provides the ability to trade an ERC20 token to another ERC20 token.
This document describes a proposal to modify the xDai Bridge as so it could use Uniswap for ETH-xDai bridging.
Since there are two direction for the bridge operations, consider both of them separately:
The Uniswap exchange contract responsible for ETH-DAI trades is 0x09cabec1ead1c0ba254b09efb3ee13841712be14.
In order to swap ETH to DAI and send them to the bridge contract it is necessary to call
ethToTokenTransferOutput with the token bridge address as the parameter (
recipient). This call will generate the
Transfer event where
from is the exchange contract and
to is the bridge contract. It also generates
TokenPurchase where the caller of
ethToTokenTransferOutput is specified in the
It means that the token bridge behavior can be changed as so:
- Every token bridge instance observes the
Transferevent where the field
tois the bridge contract address.
- It checks the
fromfield of the event in order to understand that the transfer is from the ETH-DAI exchange. It triggers the special handling of the relay request: the
buyerfield for the
TokenPurchaseevent is used to take the sender of the request rather than the field
- Every instance confirmrs the request and the corresponding amount of xDai coins minted and sent to
buyeraddress in the xDai chain.
The current implementation of the bridge assumes that the relay request is triggered as soon as xDai coins are sent to the fallback method of the bridge contract. So, there is no any possibility to specify the information if the receiver of tokens differs from the coins sender that’s why we cannot point out the Uniswap exchange as the receiver.
Since the swapping scenario assumes some special handling the following is suggested:
- A new method must be introduced in the bridge contract like
requestToSwap. This method will be payable and require at least two parameters:
deadlinethat will be calculated by the Token Bridge UI by the same manner as Uniswap Send UI does.
- As soon as the user calls
requestToSwapthe bridge contract on the xDai chain recognizes special treatment of such relay request. This is reflected on the structure of the relay message. The parameters
deadlinewill be encoded as part of this message.
- The bridge contract on the ETH Mainnet side receives confirmation of the relay message signed by the bridge validators.
- Since the message differs from the ordinary relay request, the bridge contract calls:
approvein DAI token contract to confirm swapping
tokenToEthTransferInputin the ETH-DAI exchange contract, where
recipientis the address of the relay request sender.
tokenToEthTransferInputfails (e.g. the exchange rate was changed dramatically or the transaction was picked up by the network validators to late), the bridge contract claims the token transfer approval and send the DAI tokens to the recipient instead. It will allow the user to finish exchange later with more preferable rate.
Another option could be to handle the fail of
tokenToEthTransferInput as so the tokens will remain locked on the token bridge contract and the user will need to claim/re-request swapping explicitly later. A con of this approach is absense of a notification to the end user that the relay requests failed.