Cross-chain bridge
Aztec Connect
Solidity
connext
This bridge will allow users to deposit assets into Aztec from other L2 bridges supported by Connext as well as send assets from Aztec directly to L2s.
Here is a simple bridge contract from the connext docs for reference.
The Hop protocol could also be used for an Aztec–>L2 transaction, reference, but not for an L2–>Aztec since it doesnt support arbitrary message passing. The rest of this specs assumes using Connext, but Hop would be similar.
Connext network, https://docs.connext.network/
What actions does this bridge make possible?
Are all bridge interactions synchronous, or is the a asynchronous flow?
Synchoronous
xcall
on connext. reference.We will need some tricks in order to get all of the necessary info into auxData. This may restrict some of the functionality. If slippage gets too high this bridge may become unusable.
How can the accounting of the bridge be impacted by interactions performed by other parties than the bridge? Example, if borrowing, how does it handle liquidations etc.
What functions are available in /src/client? How should they be used?
getAuxData
getExpectedOutput
getInteractionPresentValue
No
Yes. It will need to hold a mapping of ids=>address since there is not enough data in auxData
to pass an Ethereum address.
How to pack all of the required info into uint64?
Here is the xcall
interface.
Param | bits |
---|---|
_destination | 5 (for 32 destination domains) or 6 (for 64) |
_to | 24 (16.8M addresses) |
_asset | 0 (derived from input asset id) |
_delegate | 0 (can use same address as _to) |
_amount | 0 (derived from inputAmount) |
_slippage (in BPS) | 9 bits allows for 5.12% as max slippage or 10 bits would allow for 10.24% |
_callData | 0 (not needed for basic transfers) |
Total | ~39 |
Connext also requires a relayer fee. The remaining 9 or 10 bits can be used to set that. It is likely that the relayer fee can be indicated in auxData and will need to be increased by a multiplier to get it to the expected amount.
The _destination
could be reduced to fewer bits (5 bits for 32 domains, 6 bits for 64) if there is a mapping of id=>destintation in bridge contract storage. mapping(uint256=>uint32)
We'd also have to add a protected function for adding new domains. This would give more bits for _to
, _slippage
and relayerFee
For destination chains where ETH is not the fee paying asset (gnosis chain, polygon, etc), we could hardcode a swap (in the xcall
_callData
) for a small amount of ETH into the fee paying asset of the destination chain. This would enable users to do a couple of transactions (like swap more ETH for the fee paying asset if they want) while maintain anonymity. Otherwise they need to acquire the fee paying asset from another source and risk compromising their privacy.
No data restrictions, should be straightforwad.