# EIL native interop support via a new CrossChainPaymaster

## Definition of native interop

Within this document, by “native interop” we’ll mean the ability of the chains to communicate assets in a trusted manner, secured by underlying protocol. The most important feature in the context of EIL is that it allows to have “burn-and-mint” type of bridging, where on the protocol level funds are destroyed on the source chains and minted on the destination chain.

It allows to have asset transfers without the need for liquidity providers, which enables:

- low liquidity asset transfers (memecoins, potentially NFTs/ERC20s)
- asset transfers between unpopular or private chains.
- this is especially important as more institutions adopt crypto
- also, for smaller chains it might be hard/impossible to bootstrap enough liquidity providers for even the most popular tokens.

## Security notes on EIL vs native interop

Problem with overrides/disputes etc

- E.g. an attack where a bad XLP claims funds on the source chain, while not giving anything on the destination chain require a fact that the dest chains’ operator is cooperative (will process the message with proof of insolvency)
- The same is about overrides. For overrides we actually need both chains to be cooperative.
- The only thing that prevents a bad XLP from stealing funds from the other XLP is cooperatives of the dest chain to send the message about who processed the users' request.
- The problems above could be theoretically solved by always sending a “callback” message to L1 for every single EIL operation, but it would increase the costs.
- Very likely nothing can solve the issues when the destination operator is truly malicious though it depends on the constraints of the L2 in question.

The difference from native interop:

- In native interop if the dest chain is not cooperative, the funds can be at most frozen, but never stolen. In EIL, a bad operator of the destination chain with an XLP on the source chain could obtain liquid funds on the source chain by claiming to process users transaction and not giving the opportunity to dispute this fact.

## Current state: EIL is the kept as-is. The main purpose of Native Interop is rebalancing

The upsides is that EIL can be simpler and focused only on XLP-based interop.

The downsides are common for liquidity-based interop:

- Will not work for low liquidity assets (esp NFTs, but shitcoins/rare coins it is hard too).
- For a chain to become connected to interop, the XLP needs to be connected on both ends
- The only way it will be realistically resolved is by having “hub” chains through which all interop is forwarded (instead of direct interops between chains, a hop through a chain which everyone is connected to is needed).
- For small chains, there is a real risk of XLP centralization:
- Disputes rely on XLPs tracking whether another XLP is bad in a timely manner
- For unpopular chains (one XLP) it is not realistic and puts constant danger to users.

## Proposal: extend EIL to support native interop

EIL provides a nice unified interface for wallets. Let's keep this interface, but see how it affects such a native interop XLP.

### Disabling disputes over insolvency

Two main difference from liqudity-provider based interop:

- Some time is needed before the funds arrive on the destination chain
- Once the funds arrive, they will be definitely available

And so insolvency disputes should be disabled for native interop.

### Disabling disputes over unclaimed voucher

Typically interop is perpetual. Even though not all L2s support native L2<>L2 interop, all known to the author support L2→L1 withdrawals. These are *one-way* and *indefinite* (i.e. user can always withdraw).

By analogy we can imagine interop being the same way and so for simplicitly, the *vouchers are to never expire*.

This will prevent the ability to ever claim the voucher as unspent, so disputes over unspent voucher will never be activated.

### Disabling disputes over overrides

If we tried to keep overrides and allow native interop, the following scenario is possible:

- User locks funds
- The token is minted on the destination chain (via standard interop)
- Someone claims that the funds were not provided on the destination chain and tries to override the voucher on the source chain. If the destination chain is not cooperative in disputing the override, the override will succeed and the attacker will get the funds on the destination chain.
- This would mean that the tokens are present on both the source and the destination chain.

To prevent the issues from above, we should prevent the possibility for override. The best way to do so is to demand that the list of allowed Xlps is equal to 1 when user tries to provide a native-interop XLP.

### Additional changes

1. Since L2 native interop is protected by the protocol, it should not require stake.
2. Though not *strictly* necessary, but very helpful is the ability to withdraw users’ funds rightaway without the 1 hour lock window.
- it makes the logic more consistent with the native interop where before “mint” on the dest chain happens, a “burn” should happen on the source chain.
- Additionally, since no kind of dispute is possible for the native interop, this 1h timelock does not give users any additional security.
- For better UX, the funds should be withdrawable even before a voucher is available
3. CrossChainPaymaster can not expect the funds to be present inside it arrive before its execution starts.
- So it should finalize the interop (if the protocol requires it) before the execution starts.
4. Signature verification is not supported by such contracts.

### Main contribution: standardizing flow for Wallets

The easiest way to achieve all the above is to standardize the interface that wallets expect from the `OriginSwapManager` contract and the `CrossChainPaymaster` contract.

The wallets will be required to know that for chains that natively support interop a separate, alternative `OriginSwapManagerNative` and `CrossChainPaymasterNative` are available. However, once this fact is known, the same flow as before could be used:

1. User calls `lockUserDeposit` function in the `OriginSwapManagerNative` contract.
2. Wallet waits for the voucher to be issued (just waiting for the event).
1. In case of EIL, it is just XLP confirming that he has available funds on the destination chain
2. In case of native interop, it would only happen after the interop is complete and the proof required to claim the funds on the destination is available (this would allow to use the voucher without changes on the destination network).
3. (new!) Wallet would need to wait until on the destination chain the voucher is claimable. The logic is the same for both native interop and the standard EIL: the user could check that the `withdrawFromVoucher` function works in a call. We can provide a dedicated function for that. For the standard EIL the function should work immediately. For the native interop, the user would need to wait.

### Implementation and full flow

Glossary:

- `IL2NativeInteropAdapter` — an interface that encapsulates the internal implementation of the L2 native interop.
- `NativeInteropXLP` — a contract that serves as an `XLP` for the native interop. It interacts with `CrossChainPaymasterNative` / `OriginSwapManagerNative` and `IL2NativeInteropAdapter`. The implementation of this contract may depend on the exact platform, but it will be used to demonstrate how the XLP will interact with the system.

**It must have the same address on both source chain and the destination chain.**
- `EOA_Facilitator` — an EOA that will call `NativeInteropXlp` on the source chain. Usually it will be an operator or a bundler-like entity. User wallet can also perform this role. For the ease of implementation, it is better to use coinbase for it.

Performing a cross-chain operation:

1. User locks its deposit using `OriginSwapManagerNative`. This request must have exactly **one** `allowedXlps` and it should be the `NativeInteropXlp`.
2. `EOA_Facilitator` calls `NativeInteropXlp.startBridging`
1. Performs basic checks that the destination chain is supported for the native interop, etc.
2. It withdraws the users funds from the `OriginSwapManagerNative` and starts the interop
3. It can perform any additional checks needed from the user.
4. Any fees provided by the user on top of the asset transfered should be withdrawable by this contract to reward the coinbase.
3. <Wait until the interop is processed>
4. Once the native interop has been processed, the `EOA_Facilitator` calls `NativeInteropXlp.issueVouchers` and it will do the following:
1. Validate that the voucher is correct using `IL2NativeInteropAdapter`i.e. the `xlpSignature` field should be accepted on the destination chain
2. After that call `OriginSwapManagerNative.issueVouchers`
5. Once the message has passed to the destination chain, the user proceeds to use the `CrossChainPaymaster` just as before. However, the paymaster would also call the `NativeInteropXlp.finalizeVoucher` function whenever trying to withdraw using voucher. It would finalize the interop and deposit funds to the `CrossChainPaymaster`.
6. The protocol proceeds as before.

Rough PoC can be seen here: https://github.com/eth-infinitism/eil-contracts/pull/4.

### Making it generic & Wallet support

Wallets would have to hardcode somewhere the addresses for the alternative trusted `OriginSwapManager`, however it should be easy for the wallets to integrate any new implementation of native interop.

This is achieved via the standardized flow as described in the section above.

Note, that the approach from above could be used for any "burn-and-mint" or "lock-and-mint" interop, which would allow to generalize L2->L1 or L1->L2 communication too.

### Issues and alternative designs

- Under the conditions above, the users can never “Cancel” their interop request. If it is deemed an important feature, alternative flow could be allowed:
- The voucher is issued immediately, but then the xlp signature from the voucher is not working out of the box.
- In the case above, we’d need to have a standard way to convert “origin voucher” to “destination voucher”.
- Another alternative is to never allow to cancel interop, but allow anyone to finalize issuing the voucher for a portion of the fee.