Aave Portals

[LayneHaber]

Summary

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. The functionality should be restricted to a trusted set of routers, and those routers should only use the unbacked positions if there is no liquidity available. The fee they charge should be sufficient to cover the position + any interest when the full amount comes through

Motivation

Aave v3 opens up a unique design space for bridges with their portal feature. Using the portals, bridges have access to large amounts of collateral by taking on unbacked positions for the duration of the bridging. It would be incredible to be able to utilize this feature when providing fast liquidity across nomad.

Design Requirements

• The Connext.sol contract should be whitelisted as a BRIDGE on Aave
• Should default to checking if Aave collateral is an option if there is no fast liquidity available
• Should be abstracted from the user
• Positions must be closed when funds are bridged

Proposed Solution

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

Test Cases

// ========= Connext.t.sol =========

// Should enforce aave-approved routers only can use this feature
function test_Connext__execute_failIfNotApprovedForAave() public { ... }

// Should enforce only tokens with matching aTokens can use this feature
function test_Connext__execute_failIfNoAtoken() public { ... }

// Should work
function test_Connext__execute_shouldWorkWithAave() public { ... }

// Should repay loan on reconcile
function test_Connext__reconcile_shouldWorkWithAave() public { ... }

// ========= ConnextTokenRegistry.t.sol =========

// Should return the aToken for given token
function test_ConnextTokenRegistry_getAToken_shouldWork() public { ... }

// Should return the address(0) if no aToken found
function test_ConnextTokenRegistry_getAToken_shouldWorkNoToken() public { ... }

// Should return the underlying asset of the aToken
function test_ConnextTokenRegistry_getUnderlying_shouldWork() public { ... }

// Should revert if no aToken found
function test_ConnextTokenRegistry_getUnderlying_failIfNotFound() public { ... }

Open Questions

1. Malicious routers can invent transfers and create unbacked loans. While they would get slashed for doing this, they could mint up to the Aave cap of unbacked loans. While we can enable this feature to be accessible to only trusted routers, it's not clear what a more long-term solution could look like. It's possible we can enforce the value of the stake > some multiple of the loan withdrawn and routers must pay back the loan or their stake is slashed to repay it, but this would be a longer term question.
2. Are you able to repay without ever backing the unbacked loan?
3. What happens in the case the interest rates aren't fixed, and the fee cannot account for the interest accrued (or the payment is slowed beyond the optimistic timeout and more interest is incurred than is accounted for) and the router doesn't have enough liquidity to cover the costs? Presumably this is then on the router, and this is the price you have to pay for taking on the credit risk here.
4. Should we combine the two TokenRegistry implementations (a singular token registry for cross domain representations, adopted versions, and aTokens)?

Tasks

• Create ConnextTokenRegistry
• Create onlyOwner functions to maintain whitelist for portal approved routers (approveRouterForPortal(), disapproveRouterForPortal())
• Update execute
• Update reconcile
• Tests

[rhlsthrm]

Malicious routers can invent transfers and create unbacked loans. While they would get slashed for doing this, they could mint up to the Aave cap of unbacked loans. While we can enable this feature to be accessible to only trusted routers, it's not clear what a more long-term solution could look like. It's possible we can enforce the value of the stake > some multiple of the loan withdrawn and routers must pay back the loan or their stake is slashed to repay it, but this would be a longer term question.

The process of getting whitelisted for portals to begin with relies on going through governance. So not only would they have to plead their case to Aave's community, their reputation is definitely on the line there. I don't think we need to worry too much about this until very long term if we want to start adding all our routers.

[LayneHaber]

Right but the reputation isn't safeguarded. It's unclear, and also the router wouldn't necessarily have to plead their case as Connext.sol would get the role, not them.

[wanglonghong]

Malicious routers can invent transfers and create unbacked loans. While they would get slashed for doing this, they could mint up to the Aave cap of unbacked loans. While we can enable this feature to be accessible to only trusted routers, it's not clear what a more long-term solution could look like. It's possible we can enforce the value of the stake > some multiple of the loan withdrawn and routers must pay back the loan or their stake is slashed to repay it, but this would be a longer term question.

I think it could be helpful to provide fast liquidity to our bridge holders if Aave gets this done even if there are some more complex cases that we have to consider. I can see this proposal only on the governance page if I am not mistaken. but In case we assume that its already done and works well across several EVM networks, I think it would be better to have the feature to be accessible to only trusted routers in the beginning because of the security. Anyway, it can have more problems than we expect here. so could be ok to have just an interface for now if we MUST get this feature for fast liquidity.

[LayneHaber]

Right, we don't need this feature for fast liquidity, it should really only exist in the cases where the transfer is using the fast liquidity path and there's not enough liquidity available.

Also you really only need one trusted router to make use of this feature, and it could always be the sequencer as the router (or something along those lines)

[jakekidd]

Simplest implementation w/o trusted routers (that i can think of):

• Router collateralizes on 1 HQ chain
• Aave builds an xapp (using nomad) for updating the amount that the router is able to borrow on domain X

Problem here I guess is why stake on HQ chain just to supply liq on domain B? Why not just move that same liq to domain B? I mean, this would be great if we could stake on HQ and borrow on any chain, but then ofc we have the async problem enabling routers to under-collateralize.

Some other thoughts for how to crush trust requirement:

• What if Aave had an off-chain actor that "notarized" the loans based on the fact that they knew the router could pay it back? I'm thinking that they could validate that they see the transfer coming through nomad. A notary for these loans would mean that we could effectively enable Aave to delegate trust as they fit, as opposed to forcing them to trust us and our network of trusted routers...
• Would the notary necessarily have to be off-chain? Technically a notary contract could look at the onchain state and see that an unapproved nomad message is there... hmm.
• What if routers produced a warrant that promised they weren't under-collateralizing at any given moment? Validators could keep the router in check if they take all the warrants that prove that the router under-collateralized. E.g. according to the sum of these N warrants, the router sent X funds within 30 mins across S set of chains, but the router only had Y funds collateralized on each chain (where Y < X). Not entirely clear how we could make sure that we get all the lost funds back in the event that the router under-collateralizes and steals... but combined with a notary, we could certainly use this to immediately slash the router on the HQ chain and close out the router's ability to loan on every other chain immediately.

I might type up a spec for this

[LayneHaber]

Hmm I would definitely be interested in seeing more details around these ideas! An immediate concern is that relying on Aave to update their feature design in any way to mitigate this will require the buy-in of the Aave community. It's highly likely they would want whatever solution we come up with here to be portable across all bridges they authorize, which ultimately becomes a process involving setting standards across disparate projects and would definitely not get included in the timelines we have to work with. That being said, since it would be a long process it's not a bad idea to start thinking about some potential solutions up front.

routers produced a warrant that promised they weren't under-collateralizing

could use some more clarification around what you mean by this as well -- the feature from Aave is to specifically allow uncollateralized credit for bridges. Are you talking about ensuring there is a transfer coming out to square the position?

Also, does this inherently depend on staking to enforce good behavior from routers? I'm not opposed to it, but important to note the added capital inefficiencies (and if this is the path we want to pursue we would likely need to find some workable shorter-term solution since it seems unlikely we'd be able to stand that up in time)

[rhlsthrm]

This is kind of interesting. I've been thinking of a design that you could build as a "cross-chain flash loan" that used a similar design where you could loan based on the fact that you can "see" that the Nomad transfer was coming back to repay you.

[rhlsthrm]

and if this is the path we want to pursue we would likely need to find some workable shorter-term solution since it seems unlikely we'd be able to stand that up in time

I just don't see the point in doing this in the short term. Aave has already gone over this with us and this is the same design they will use for other bridges. It's nice to think about it trustlessly but this is much farther out.

[LayneHaber]

yeah agree, going to convert this into a spec with these trust assumptions embedded

[patitonar]

Here are some useful links:

• Aave V3 technial paper - 4.5 Portals (Page 12)
• Link to the Aave entry methods code
• Link to Aave BridgeLogic Impl for mintUnbacked/backUnbacked

After reviewing all, here are some comments/questions:

1. When calling backUnbacked to repay the underlying assets Connext will need to provide the amount and fee. The protocol as detailed in the docs and the code, does not enforce any value on the fee parameter so is not clear how to calculate this.
2. There are no track records of the amounts minted and/or backed by an address on-chain so we will probably need some off-chain component to keep track of this. Maybe Aave has some tools for this?
3. Given that the method backUnbacked is only called by the bridge role, Do we need some emergency repay method or something in case Connext needs to repay more assets into Aave (In case of malicious router minted without incoming transfer, or any bug or accounting issues, etc)?
4. What if the Aave fee is lower than the router liquidity fee? Would this be possible? Should we explore ways to use Aave liquidity instead of routers liquidity when possible in that case to benefit users? (I'm not sure this makes sense, I may be missing a lot of things here)
5. This one sounds more like a completely new feature that can be built on top (with some changes on the core) to increase the love of the Aave community for Connext to allow us as BRIDGE role. Beyond using Aave Portal to increase Connext liquidity, it can be used to provide new functionality for Aave users like moving assets deposited between Aave markets on different domains. For example, transfer aDAI from one domain and get aDAI on the destination domain. Probably this can be build by adding a contract that receives the aToken, redeem it for the underlying and interact with Connext specifying that it wants to receive the aToken representation on the destination, son in execute it will transfer the aToken directly instead of unwrapping it.

[LayneHaber]

Thanks for adding the links! Good to have a reference here.

1. Yes, although I believe in a discussion Marc posted here that they would use a fixed-fee. I think we will need an Aave-liquidity fee that we can tune along with the fee the Aave protocol uses. It would be nice to calculate that all onchain though.

2. Yeah definitely, we could build this into the subgraph and change some of the event information if needed. Should be doable

3. I think it wouldn't be a horrible idea to have an emergency repay function -- i.e. if nomad agents go down before you get the incoming collateral to repay the assets you would likely need some way to swap some of your liquidity to repay since the fees could be higher than expected.

4. I think that would be interesting, but they would be paying 2x fees -- one fee to the router for taking on the credit risk, and one fee to Aave for the debt. It may still be lower though, but since this is a trusted credit line I would be hesitant to bake it in as the default

5. That definitely sounds like a much cleaner architecture, what is your ideal layout for that?

[rhlsthrm]

There are no track records of the amounts minted and/or backed by an address on-chain so we will probably need some off-chain component to keep track of this. Maybe Aave has some tools for this?

That seems like an oversight, interesting. Seems like you should be able to get your owed amount directly from their contracts.

[patitonar]

5. That definitely sounds like a much cleaner architecture, what is your ideal layout for that?

I realized my comment is a little confusing. So to clarify, my comment about "completely new feature that can be built on top" was related to the new functionality I mentioned about aTokens to aTokens for Aave markets for users. Regarding this described proposal for increasing liquidity when no fast-liquidity is available I think it looks good. Of course, it would be great if this is something that can be built on top too, but given the requirements, security concerns and how Connext works I'm not sure it is possible to avoid introducing the explained changes to execute and reconcile

[LayneHaber]

Cool! Building the feature with the aTokens directly may impact how some of the base layer changes are made because you don't want to introduce slippage if you don't have to. I think that is likely unavoidable because the bridge delivers you wrapped assets and on execute there would be no additional AMM call just wraps and unwraps