Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arbitrum gateways #57

Open
wants to merge 13 commits into
base: master
Choose a base branch
from
Open

Arbitrum gateways #57

wants to merge 13 commits into from

Conversation

aalavandhan
Copy link
Member

@aalavandhan aalavandhan commented Oct 13, 2021

AMPL Arbitrum Bridge gateways.

To test the UI:

  1. Goto https://bridge.arbitrum.io/ and connect to the Rinkeby testnet.
  2. Add the AMPL testnet deployment address "0x244E12361f488adFa757E706466023673a96Fa3d" to the token list.
  3. This should pull up the counterpart L2 address and allow you to send AMPL from rinkeby to arb testnet.

@aalavandhan aalavandhan force-pushed the xc-wampl branch 3 times, most recently from 7b7a7ca to 34ed3b8 Compare October 25, 2021 16:07
@aalavandhan aalavandhan changed the base branch from master to token-upgrade October 25, 2021 16:08
Base automatically changed from token-upgrade to master November 2, 2021 18:27
@@ -16,14 +16,12 @@ import {IXCAmple} from "../../_interfaces/IXCAmple.sol";
* the xc-ample contracts.
*
*/
contract MaticXCAmpleRebaseGateway is Layer2RebaseGateway, FxBaseChildTunnel {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initially assumed we could abstract all L2s to implement the same gateway interface, however there are operational differences between L2s which prevent this.

eg) Matic doesn't charge a ETH fee to send data from ethereum to matic but Arbitrum does. Arbitrum expects the caller to "pre-pay" the storage and execution cost of the cross chain transaction and thus has some additional parameters.

Leaning toward defining separate gateway interfaces for each bridge.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. Unfortunately I think it's unlikely these bridges will be similar enough to abstract away completely.

IERC20(_l1Token).safeTransferFrom(from, address(this), _amount);
IERC20(_l1Token).approve(vault, _amount);

ITokenVault(vault).lock(_l1Token, address(this), _amount);
Copy link
Member Author

@aalavandhan aalavandhan Dec 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We do this to keep the audit trail on the vault. Explicitly calling lock over just transferring directly into the vault logs the GatewayLocked event.

https://github.com/ampleforth/cross-chain-ample/blob/master/contracts/base-chain/TokenVault.sol#L31

However I wonder if the GatewayLocked and GatewayUnlocked events are redundant as one could always reconstruct the same information using merely the token transfer logs.

If so we can safeTransferFrom the user's wallet directly into the vault which is cleaner and more gas efficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants