Subsidize fees and risk

[TorstenStueber]

For each offramp flow the user would need to pay different fees and has to face exchange rate risk:

Fees

• on Polygon: transaction fees for swapping USDC to axlUSDC and to execute the Axelar bridge (including transaction fees for automation on Moonbeam) – about 0.4-0.5 MATIC
• on Pendulum: XCM fees (about 0.02 USDC.axl) and transaction fees (about 0.01 PEN)
• on Stellar: transaction fees (about 0.1 XLM)

Exchange Rate We need to execute two exchanges, once from USDC/USDC.e to axlUSDC and once from axlUSDC to EURC. We will predict the exchange rate for each of them but can't guarantee that they will be realized so that the user might receive fewer tokens in exchange than expected.

All fees (except the MATIC fees on Polygon) and all risk should be subsidized.

High Level View

Subsidize fees

Subsidizing the fees on Pendulum and Stellar should happen through the funding accounts of the ephemeral accounts – just by funding enough initial value that is sufficient to pay for transaction fees. After the transactions have been executed, the ephemeral accounts should be closed and remaining funds should be moved back to the funding account.

Note: this is already the case, no work required

Subsidize risk

The transactions that are executed after the USDC/USDC.e -> axlUSDC swap and after the axlUSDC to EURC swap encode concrete values and therefore make assumptions about how much return values these swaps yield.

Since we want to construct and sign all the transactions right at the beginning of the offramping flow (and store them on the backend in order to prevent loss, see https://github.com/pendulum-chain/vortex/issues/58), we would need to subsidize missing amounts immediately after the swaps:

• for the USDC -> axlUSDC we would need to subsidize the remaining axlUSDC balance right after the tokens arrive on Pendulum
• for the axlUSDC -> EURC swap we would need to subsidize the remaining EURC balance right after the swap with our Forex AMM

These two subsidizing transactions cannot be constructed a priori because the missing amount is only known after the swaps. The transactions need to be constructed on the backend.

TODO

• add two POST endpoints to the backend
  • the first endpoint takes 1) a USDC.axl amount string (in units) and 2) a target Pendulum address and will transfer the specified amount (in USDC.axl) from the funding account to that target account
  • the first endpoint takes 1) an amount string (in units), 2) an output token type (eurc or brl) and 3) a target Pendulum address and will transfer the specified amount from the funding account to that target account
• add two more phases into the execution flow
  • one before the Nabla approval, this one determines the missing USDC.axl amount that is required to execute the swap and will call the first endpoint and wait for the funds to arrive
  • the other after the Nabla swap, this one determines the missing output token amount that is required to execute the offramp and will call the second endpoint and wait for the funds to arrive
• remove the logic in useTokenOutAmount that reduces the "from amount" by xcmFees, slippageBasisPoints, axelarSlippageBasisPoints
  • these three configuration parameters then can be removed from the configuration, they are not required anymore

Open Questions

How to do this in a way that cannot be gamed (e.g., someone forges wrong information and receives more tokens than justified) without introducing state in the backend?

[TorstenStueber]

Hey team! Please add your planning poker estimate with Zenhub @b-yap @bogdanS98 @ebma @gianfra-t

[gianfra-t]

@TorstenStueber When you say not introducing any new state in the backend, what exactly do you mean? Because one easy way of doing this would be for the client to provide the axelar transaction hash and the backend verify this, only then fund the ephemerals.

[ebma]

I think this ticket just still assumes that the funding accounts are stored locally and not in the backend. That's why also the changes for this ticket should happen locally otherwise you'd have to move the other logic to the backend too which is out of scope here.

[gianfra-t]

But then there is not really much of a point in finding a way in which the user cannot game this, since any sort of proof or verification will be done locally and would have the same level of security just with more complexity.

Maybe before developing this part we need to move the funding account's data and logic out of the UI ? We could also do this along with this changes.

[ebma]

To decide, we would need to guess the overhead of a) first adding the subsidizing for local funding accounts and later moving that logic to the backend vs b) moving the funding to the backend + implementing the subsidizing to it.

We can have a) implemented faster, so this feature would go live sooner, but in contrast to b) we'd implement code that we'd have to remove soon after.

[TorstenStueber]

The Stellar funding account is securely managed on the backend. Only the Pendulum funding account is in the frontend now and insecure – but this decision happened after I wrote this ticket here.

Let's assume the Pendulum funding account is also managed in the backend – otherwise we don't need to ask the question about security and non-gameability in the first place.

Under this assumption: the backend would then execute subsidizing the account. I assume that we implement an endpoint for this. How does the endpoint check that the call to it is valid and not forged?

[gianfra-t]

I think the issue is that, as long as the user has full control of the ephemeral (unlike the stellar ephemeral), any solution to check if the call was verified or not (for example, check if the user made the bridge using the axelar api) would have the same level of security as now because the user could just stop the offramp at any time and withdraw the subsidized amount, which is something that cannot happen with the stellar one.

[prayagd]

@TorstenStueber i assume some inputs required from Product here, can you please let us know what that would be?

[TorstenStueber]

@gianfra-t yes, you are right in principle. However, the funding is a limited amount and subsidizing could be much more. Of course someone could spam the funding endpoint but I still consider the subsidizing endpoints more important to protect. But I am fine if we first go for the unprotected approach and can add some protection layer later.

@prayagd I don't think that there is input required.

[TorstenStueber]

I added a TODO section with technical details. (@gianfra-t this is the zero security version)

@prayagd this is now ready