# L2<>L2 Bridge via Connext

###### tags: `Cross-chain bridge` `Aztec Connect` `Solidity` `connext`

## Spec

1. What does this bridge do? Why did you build it?

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](https://docs.connext.network/developers/examples/simple-bridge) is a simple bridge contract from the connext docs for reference.

The Hop protocol could also be used for an Aztec-->L2 transaction, [reference](https://docs.hop.exchange/smart-contracts/integration), 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.

2. What protocol(s) does the bridge interact with?

Connext network, https://docs.connext.network/

3. What is the flow of the bridge?

- What actions does this bridge make possible?

- Deposit ETH or DAI from an L2 directly into Aztec
- Withdraw ETH or DAI from Aztec directly to an L2

- Are all bridge interactions synchronous, or is the a asynchronous flow?

Synchoronous

- For each interaction define:
- All relevant bridge address ids (may fill in after deployment)
- TBD
- use of auxData
- would be need to specify the inputs to `xcall` on connext. [reference](https://docs.connext.network/developers/reference/contracts/calls#xcall).
- auxData would need to encode
- the destination chain (uint32)
- the destination address
- slippage (uint256, but can be much smaller)
- relayer fee (uint256, but can probably be smaller)
- gas usage
- TBD
- cases that would make the interaction revert (low liquidity etc)
- high slippage
- insufficient relayer fee
- Please include any diagrams that would be helpful to understand asset flow.

[diagram](https://docs.google.com/presentation/d/1qDcdKarKNCmZHXlplTIr4WVcFrROxjC1z0u26y13Wyc/edit?usp=sharing)

4. Please list any edge cases that may restrict the usefulness of the bridge or that the bridge prevents explicit.

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.

5. 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.

6. What functions are available in /src/client? How should they be used?

- `getAuxData`
- TBD
- `getExpectedOutput`
- TBD
- `getInteractionPresentValue`
- TBD

7. Is this contract upgradable? If so, what are the restrictions on upgradability?

No

8. Does this bridge maintain state? If so, what is stored and why?

Yes. It will need to hold a mapping of ids=>address since there is not enough data in `auxData` to pass an Ethereum address.

9. Any other relevant information

## AztecToL2.sol

How to pack all of the required info into uint64?

Here is the `xcall` interface.

function xcall(uint32 _destination, address _to, address _asset, address _delegate, uint256 _amount, uint256 _slippage, bytes _callData) external payable returns (bytes32)

| 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](https://docs.connext.network/developers/guides/estimating-fees). 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.

## L2ToAztec.sol

No data restrictions, should be straightforwad.