Below is a proposal to implement a new functionality for the TokenBridge to transfer DAI tokens through the bridge with simultaneous change of the receiver account. It will allow to specify receiver of the tokens.
Background
Currently ordinary TokenBridge operations (not Arbitrary Message Bridging) assume that an account that receives tokens is the same as the account that sends the tokens.
Let’s consider the scenario when Alice transfer tokens through the xDai bridge:
- Alice sends xDai to the bridge contract. The contract implicitly called through fallback function extracts Alice’s account address from the transaction parameters and generates an event where this address is specified as the receiver of the tokens.
- The TokenBridge oracles confirm this relay request by sending signatures to the bridge contract on the Ethereum Mainnet side.
- The bridge contract transfers corresponding amount of DAI tokens to the Alice’s account in the Ethereum Mainnet.
Similar is performed if Alice transfers tokens in the opposite direction from the Ethereum Mainnet to the xDai chain.
- Alice transfers DAI tokens to the bridge contract by calling the
transfer
method on the token contract. - The TokenBridge oracles catch the
Transfer
event targeted to the bridge account and consider it as a relay request. The fieldfrom
of the event data (which is Alice’s account address) is used as the receiver account address for this relay request. - The oracles confirm the relay request by sending transactions to the bridge contract on the xDai chain side.
- The bridge contract registers the request (receiver and value) in the block reward contract.
- The new block is minted with participation of the block reward contract as so the receiver account balance is increased by the requested amount of xDai.
These examples demonstrate that it is not possible to explicitly specify a receiver on the step 1 of every scenario. So, another sequence of operations is needed to implement required functionality.
Proposal
In order to implement the Alternative receiver functionality the new scenario is being suggested. Whether a user transfers tokens either from the xDai chain or from the Ethereum Mainnet, the bridge contract should be called explicitly.
For the transfer from the xDai chain it means that the user needs to invoke a special method (e.g. relayRequest
) of the bridge contract and specify the receiver of the tokens.
function relayRequest(address _receiver) payable external {
require(_receiver != address(0));
require(msg.value > 0);
// ...
// some code here
// ...
emit UserRequestForSignature(_receiver, msg.value);
}
Since the method is payable the corresponding transaction will have both the input
data to handle the method invocation and the value
of xDai. The bridge contract will use the address specified in the method parameters to notify the oracles about recipient of tokens on another side of the bridge.
The user’s actions to transfer tokens from the Ethereum Mainnet consist of two parts:
- The user invokes
approve
method of the DAI token contract and specifies the bridge account to be allowable to transfer some specific amount of tokens. - Then the user invokes a special method (e.g.
relayRequest
) on the bridge contract, specifies the amount of tokens to be transferred through the bridge and the receiver account address.
function relayRequest(address _sender, address _receiver, uint256 _amount) public {
require(_receiver != address(0));
require(_receiver != address(this));
require(_receiver != bridgeAddressOnxDaiChain);
require(_amount > 0);
// ...
// some code here
// ...
bridgeableToken.transferFrom(_sender, address(this), amount);
emit UserRequestForAffirmation(_receiver, amount);
}
function relayRequest(address _receiver, uint256 _amount) external {
relayRequest(msg.sender, _receiver, _amount);
}
The bridge contract invoked through the method will collect approved amount of tokens by transferFrom
and notify the oracles about recipient of tokens on another side of the bridge.
Extra
It is necessary to note that these suggestions do not change existing behavior of the bridge it will still support methods to transfer tokens described in the background section.
In order to achieve this the only modifications are needed is to add one more listener on the TokenBridge oracle side to catch the UserRequestForAffirmation
events.
Another useful point is that checking of transfer limits can be performed in proper way for the requests initiated through the relayRequest
method so the risk to exceed the limit for transfer from the Ethereum Mainnet to the xDai chain will be eliminated.