Consistent Amounts

[LayneHaber]

Motivation

The amarok hardfork of nxtp is built on top of the nomad token bridge. The nomad bridge will lock tokens on some origin domain, and mint mad-assets (representations of the original locked asset) on the destination domain. On domains where there is already an adopted/commonly used asset, this can lead to lots of added complexity (i.e. if you are using nomad to exit usdc from polygon you get mad-pos-usdc). To address this, nxtp has a stable swap built in to swap between adopted assets and mad assets. If you are bridging usdc from polygon to arbitrum, for example, you would:

1. Send pos usdc to nxtp contracts
2. Swap into madUSDC on polygon
3. Bridge the madUSDC (references some USDC locked on mainnet)
4. madUSDC bridged from polygon gets burnt, new madUSDC on arbitrum is minted
5. Swap out of madUSDC on arbitrum
6. Collect adopted USDC on arbitrum

The problem arises when you try to make use of calldata. NXTP allows for arbitrary calldata to be passed through the system so you can execute some function on a destination domain without writing middleware contracts. Unfortunately, most functions require an amount to be included in that calldata (i.e. a swap), which is difficult to include when using AMMs (in the above example, how do i know what the ultimate arbitrum usdc value will be a-priori).

Design Requirements

• Be able to easily include the amount in the destination domain calldata context
• (ideal) Not have to write any middleware contracts

Proposal

There are a few options:

Use exactOut

One way to solve this problem is to create an exactOut path so you know exactly how much you will receive on the destination chain. This does allow you to calculate the amount to be used in the calldata up front, but just shifts the uncertainty around amounts to be on the amount you put in not what you get out.

Expose amount

This would allow contracts that need the amount delivered in the calldata to create simple parser contracts that construct the appropriate arguments. The problem here is it does require middleware contracts to account for the amount properly.

Get rid of AMMs

Using mad assets

This is relatively straightforward on the destination domain (router supplies liquidity in adopted asset, takes on risk for stable swap either independently or when the funds travel through the bridge), but much more difficult on the origin domain. Imagine the case where you exit polygon without the AMM swapping pos-usdc for mad-usdc -- the router would get reimbursed with mad-pos-usdc and you would either need a funded amm on the destination domain to swap for the right asset, or come up with a way to properly unwind. This introduces much more complex liquidity management, but the amount bridged would be easily calculated.

Liquidity pools

Another way to remove AMMs is to make use of liquidity pools and abandon bridge assets completely. In this model, instead of funding an AMM you would fund a liquidity pool. Routers would front their own capital in the same manner, and rather than using a nomad router that mints assets, we would use nomad to pass authenticated claims on the pool from one domain to another. This improves capital efficiency (just have to fund fast liquidity + pool rather than both sides of an AMM), but introduces liquidity imbalances across domains. You could introduce VAMMs to solve that, but this adds an additional layer of complexity and comes with its own drawbacks.

Open Questions

1. Would parser-like contracts have to be audited?
2. Would contracts have problems with using the exactOut path?
3. How many use cases exist where you would never need to write a middleware contract?

[jakekidd]

This would allow contracts that need the amount delivered in the calldata to create simple parser contracts that construct the appropriate arguments. The problem here is it does require middleware contracts to account for the amount properly.

This is, imo, the easiest tradeoff here. Again imo, but the whole "requires middleware contracts" is a great opportunity for us to establish common patterns / practices for devs building xapps.

Do you need the exact amount as input to your contract? Use our ExactAmountFormatter middleware contract - even just as an example / starting point.

I see this making the most sense short-term for sure, and I think devs will understand the decision-making behind it. Long term, we'll want to consider providing an option to do exactOut for other specific use-cases I think.

[LayneHaber]

Right but there's security overhead for every contract, which can become onerous and kind of destroys the point of arbitrary calldata anyways (i.e. we could just define an interface instead of using the .call functionality). And while it does allow us to create standards, I don't think not having it would prohibit us from creating example contracts serving the same purpose.

That being said it certainly is the most straightforward, the middleware contracts would be simple, and you could combine it with exactOut so you have both options if input uncertainty isn't a problem for your application

[jakekidd]

I'm missing the component where it creates security overhead?

It really delegates the issue of security (i.e. relaying the correct amount) to the middleware contract).

Am I correct in imagining that we're talking about making amount part of the standard "reverse API" on the destination domain? Like originSender and amount would both be things you retrieve through sep. read functions?

[LayneHaber]

It really delegates the issue of security (i.e. relaying the correct amount) to the middleware contract).

That's the security overhead -- it's not with respect to us but with respect to integrators. Imagine I just wanted to make a uniswap call on a different domain, I need to write a contract to do that now and should probably get it audited.

Am I correct in imagining that we're talking about making amount part of the standard "reverse API" on the destination domain? Like originSender and amount would both be things you retrieve through sep. read functions?

Yeah could do that -- though I wouldn't call it "reverse API"

[maxklenk]

Would contracts have problems with using the exactOut path?
While exactOut would be great on the destination chain, it creates problems on the sending side. We e.g. swap some token into USDC before passing it to to the bridge. With flexible inputs we would need to transfer some USDC back to the user - which is doable but not ideal.

Still having an exact amount on the destination chain is needed for many use case, e.g. when working with DEX aggregators, the callData can not be adjusted to update the passed amounts.

For those calls which require an exact amount a reusable middleware contract could be added, which can pass arbitrary calldata, gets information which token and exact amount is needed for the call and has access to a fallback address. After executing the call with the intended amount, it could refund the remaining balance to the fallback address. This would require additional passed parameters, but e.g. a fallback address if the contract call fails as in nxtp may be needed. This could be combined with fee refunds if they happen on the destination chain.

[LayneHaber]

Right -- the alternative we're striving for is to not have the need for middleware at all (i.e. provide some route to calculate this accurately when generating the calldata). Part of me wonders how likely it is that someone with these requirements would not have to write any contracts. If you have to write 0, its very useful to not introduce these middleware patterns. If you have to do 1, its exponentially less useful.

I suppose wallets are a big exception here -- i..e if they wanted to do a swap it wouldn't require any additional contract changes.

[wanglonghong]

It would be really helpful to devs who build the xapps if we get this feature.
Even if we have a few problems described above ^^, devs can build xapps on top of connext without much complexity.
What my question here is how we can get this feature implemented with varying swap rate of StableSwap. Its swap rate isn't 1 ideally and it will change from time to time. so I am not sure how we can expect the swap rate accurately when swapping the mad asset into the adopted asset. Unfortunately, I don't see a solution for this case. I'd like to listen your good idea about this as well.

To have a fallback address is absolutely needed as calldata arguments for some failure cases.

[LayneHaber]

Hm yeah the stable swaps are the source of this complexity. My main question is whether it's problematic for contracts to use swapExactOut like functions (though that just shifts the uncertainty from the amount you get out when you swap to the amount you put in).

Liquidity pools are nice, but the rebalancing becomes a really difficult problem really quickly. Even if you were to do something like virtual AMMs the fact that slow liquidity exists makes that type of pricing extremely problematic