Phase 6B: Start Anchor flow before Nabla transaction

[TorstenStueber]

Context

Follow-up ticket to phase 5. There are two important steps happening in the flow: a) execution of the Nabla swap and b) letting the user transition through the anchor UI flow.

This ticket is about changing the order of these steps.

There are two tickets for phase 6, the other one is https://github.com/pendulum-chain/pendulum-pay/issues/35

Reasoning

In later iterations of this prototype we intend to implement a flow where the user starts the offramp process on a different parachain or a different blockchain ecosystem.

For that reason many minutes can pass until the Nabla swap can be executed (e.g., sending tokens through an Ethereum bridge). However, we intend that all user interaction happens right at the beginning, before the offramping flow starts.

Although this is not that critical right now (the Nabla swap is the first step to happen and therefore the user does not need to wait for long), we already want to explore solutions to this challenge early on.

Challenge

In order to execute the anchor flow, we already need to be able to estimate the outcome of the Nabla swap. If the actual outcome will be less than the estimated amount, then the offramp cannot be completed as a higher offramping amount has been registered when the user executed the anchor flow.

We will employ the minimum swap amount parameter for the Nabla swap, this will ensure that the swap will fail if the minimum amount cannot be achieved.

TODO

• the UI displays the estimated output amount of Nabla for the input amount specified by the user; don't display the verbatim amount returned by Nabla but subtract 0.2% from that amount (called the "reduced estimated output amount")
• prefill the reduced estimated output amount when starting the anchor flow
• after the anchor flow: if the amount entered by the user is higher than the estimated output amount, then don't start the offramp flow and show an error message instead
• for the Nabla swap, specify the reduced estimated output amount as the minimum amount
• if the Nabla swap fails, then display an error to the user

Shortcomings and Outlook

This section is only relevant for later iterations.

If there is high activity on Nabla and the time between the user interaction (anchor flow) and the Nabla swap is long (e.g., when the first step is a transfer through an Ethereum bridge), then there is a chance that the estimated output amount of Nabla is not valid anymore.

In this case we could use some temporary funds to execute the Nabla swap early – as soon as the user interaction is completed.

[ebma]

don't display the verbatim amount returned by Nabla but subtract 0.2% from that amount (called the "reduced estimated output amount")

Why is it 0.2%? Is this chosen arbitrarily or is there a reasoning behind the value?

[TorstenStueber]

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

[TorstenStueber]

I chose this totally arbitrarily. It cannot be zero and it should be less than the intended slippage (which should just be a few basis points). So I thought 0.2% might be okay. We can go lower as well but that makes it more likely that the transaction will fail. @pendulum-chain/product what do you think?

[ebma]

What are we doing with the remaining funds in case the swap rate remains totally stable?

[TorstenStueber]

Right now the difference will stay on the user account. Any better solutions are probably too complex for the prototype (at least I don't see a simple and obvious solution – apart from sending the difference to some kind of treasury).

[ebma]

I see. Not ideal but also not problematic if the tokens remain with the user 👍

[vadaynujra]

For that reason many minutes can pass until the Nabla swap can be executed (e.g., sending tokens through an Ethereum bridge). However, we intend that all user interaction happens right at the beginning, before the offramping flow starts.

@TorstenStueber Is it this reasoning or rather that the user will need to execute the anchor flow many minutes later, because of which we're doing all of this. If it was just Nabla, the time based price risk is the same as we're defining for this requirement, no?

On the 0.2% part (how do we want to call it?), let's define it in a way that it can be changed easily such that in theory we could just start with some number, and then balance out the overall fees deducted for the user vs the likelihood of the transaction failing.

@prayagd can you also review and share your agreement?

[TorstenStueber]

Is it this reasoning or rather that the user will need to execute the anchor flow many minutes later, because of which we're doing all of this. If it was just Nabla, the time based price risk is the same as we're defining for this requirement, no?

There is the same price either way, but it has different effects on the whole flow:

• if doing the anchor UI after Nabla is executed, it can be that the user will get out less than originally expected, but they can still successfully continue the offramp (by specifying an accordingly smaller output value in the anchor UI)
• if the anchor UI flow comes first, then the user would already commit to a specific output amount; if Nabla will not be able to realize this output, then the funds become stuck

[vadaynujra]

Both your options assume that the user necessarily needs to do the anchor step and I'm suggesting adding that to the 'Reasoning', that's all.

[prayagd]

@prayagd can you also review and share your agreement?

i dont have a better solution to provide so I agree to keep it to 0.2% until the token remains in the user's account, as Torsten mentioned reducing it further might lead to failing of the swap operation. also IMO this is just for the prototype so we can ahead with this number, we can iterate over the findings once its live.

On the 0.2% part (how do we want to call it?)

I propose to call it "Minimum amount" as that is the least we can offer if there is any rate changes

[TorstenStueber]

We should be able to move this to Ready now.

[vadaynujra]

As discussed in today's sync, let's go ahead with SEP-24, for the initial prototype we can even keep the 0.2% substraction in place on Nabla.

[vadaynujra]

@TorstenStueber can this already be moved to staging to test or still requires some work?

[prayagd]

Closing this as the linked PR's are merged