As a router, I want the ability to borrow additional liquidity from AAVE (offchain side)

[alexwhte]

Problem

If routers do not have enough liquidity readily available, we want users to still be able to bridge. The contract side is implemented but we don't have code in place to effectively make use of this yet.

Ideas to solve this

Using Aave v3 portals when there is no fast-liquidity available to facilitate a transaction increases the capital efficiency of Amarok as a liquidity layer on top of the nomad message passing infrastructure.
https://github.com/connext/nxtp/issues/1059

Acceptance Criteria

[ ] Where router does not have liquidity, it defaults to checking if AAVE is an option [ ] Only available to allowlisted routers [ ] Positions must be closed when funds are bridged

Other

From #1059 The changes should be isolated to the execute and reconcile function calls.

In execute if there is no fast liquidity available, the function should check a registry to see if (1) there is a corresponding aToken available on the chain and (2) if the given router has permissions to use Aave collateral. If both of these are true, then the router can call mintUnbacked to get an uncollateralized credit line and deliver the adopted asset to the user. Otherwise, the function reverts.

Once the mad assets are delivered by nomad, the contract should swap into the correct adopted asset and repay the loan + interest.

A step-by-step breakdown of this proposal is:

execute

1. Check to make sure there is sufficient liquidity
2. If there is, proceed with the normal transfer flow
3. If there is not, check to see if the router can support Aave liquidity. If the router is not approved for this feature, revert
4. Check to see if there is a corresponding aToken for the desired adopted asset. If there is not, revert
5. Call mintUnbacked for an amount equal to principal - liquidity fee. Note here that there is not an additional fee because liquidity is being provided by Aave. Instead, the default liquidity fee should be high enough to pay the interest back on the position
6. Store an indicator that this transfer was supported via credit lines
7. Unwrap the delivered aToken for the adopted asset
8. Proceed with the normal execute flow (either execute the calldata or send the funds to the user)

reconcile

1. Check to see if the transfer was supported via credit lines. If it was not, follow the normal reconcile flow
2. If it was, swap into the adopted asset from the madAsset. If this is not enough, then additional liquidity should be withdrawn to close out the position.
3. Call repay with the underlying asset
4. Resume with the standard reconcile flow

Domain Requirements

• Must have Aave deployed
• Must have Connext listed as an approved BRIDGE on deployed Aave
• Must have a token registry that connects mad, adopted, and aToken assets

[alexwhte]

New xcall comes in, can I afford it? If not Given I have access to AAVE portals as a router

• Check what assets are in the Portal (Does it have what I need?)
• Have I hit my limit? (What is my limit?)

[alexwhte]

Note: How do we display this to the user up front in the UI? Meaning setting expectations around fast vs slow liquidity, fees they will pay, etc

[LayneHaber]

not planned