Phase 6A: Reduce user signing from 3 to 1 transactions

[prayagd]

Context

Follow-up ticket to phase 5. Currently the user has to sign 3 different transactions on the phase 5 version. This ticket to club all them in one single transaction.

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

Requirement

Similarly to our flow on Stellar, the prototype should create a Pendulum ephemeral account for the user.

TODO

• at the beginning of the flow create a new random keypair for Pendulum that will only be managed in the browser – this is the Pendulum ephemeral account (PEA)
• before we start to submit the first transaction (which right now is the Nabla approval transaction), create a batch transaction that sends
  • the specified USDT to the PEA
  • 1 native token to the PEA (to pay for transaction fees)
• let the user sign this transaction and submit it
• once successful, create three transactions for the PEA and sign them directly in the browser
  • Nabla approval
  • Nabla swap
  • Spacewalk
• once the Spacewalk transaction is completed, read the remaining account balances of the PEA (native, input and output tokens of the Nabla swap)
• create, sign and submit a final transaction for the PEA that sends these tokens back to the user account
  • implemented as a batch transaction
  • only add tokens that have a non-zero balance to the batch
  • for the native token: use transfer_allow_death

Shortcomings and Outlook

This section is only relevant for later iterations.

The PEA needs to have some native tokens in order to pay for transaction fees. The solution of this ticket requires that these tokens are "donated" by the user itself. This might not work at later iterations when the offramping flow will start on a different chain as native tokens will not be available.

Alternatively, we can use a funding account to provide these tokens. However, there is no multisig solution comparable to Stellar that will ensure that the user can't defraud us of these funds.

It could be that a safe solution can only be achieved with some custom onchain logic ("automation pallet").

[prayagd]

How to technically achieve this?

• Can the Epepheral logic can be implemented on Pendulum? the user account sends funds to Epepheral account and then the Epepheral account does all the signing of all the upcoming transactions cc @pendulum-chain/devs

Reason to raise this ticket -> Currently the phase 5 does stay true to the statement of "Single click offramp". so this a follow-up ticket for it.

[vadaynujra]

@prayagd based on this discussion, updated this to call it the next Phase i.e. 6. Please make necessary changes to other tickets as a result?

[prayagd]

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

[prayagd]

@TorstenStueber Can you please fill in the technical details?

[TorstenStueber]

Details added.

[vadaynujra]

@pendulum-chain/devs this ticket is ready and can be worked in parallel with Phase 6B.

[gianfra-t]

Maybe it is better to redefine this ticket and work directly on the implementation required for the polygon phase prototype, specifically this task?

I think this will involve more or less the same steps described right now, but the difference would be that we should monitor for the arrival of the tokens via XCM to kick the process instead of the user transferring to the ephemeral account.

[ebma]

True, we could consider skipping this and directly focus on the pendulum-chain/vortex#43. However, it might make sense to already build the foundation for pendulum-chain/vortex#43 in this task and make it easy to just amend the polygon logic it. This ticket is quite well-defined and already actionable while pendulum-chain/vortex#43 is not really. I fear that pendulum-chain/vortex#43 would get too large and a bit confusing if we are doing too many things at the same time. What do you think @gianfra-t? Do you think it's too much overhead to do both this and pendulum-chain/vortex#43 iteratively?

[gianfra-t]

No you're right we can keep this one but I would just keep in mind when doing it the final goal, such that not much logic is done that later has to be removed. I honestly cannot think right now if it will be too much overhead to make this change, but testing always takes time.

So, maybe we start working on this one on the parts we know will be required for both scenarios. That would be the creation of the temporary account and the replacement of the signatures. In the meantime we can define what are the actual steps to be done on pendulum-chain/vortex#43. The other thing is that pendulum-chain/vortex#43 will be large and confusing, but we know for sure how the XCM transaction will look like, so "downstream" of that it can be worked on.

[ebma]

Sounds good 👍

[TorstenStueber]

@gianfra-t As you already identified the main change to the ticket as it is specified right now is:

• how to trigger this? I think this is something we can worry about when we integrate this ticket into the complete flow (e.g., pendulum-chain/vortex#43)
• who funds the ephemeral account: that is the main question; for now my working assumption is that this is funded by us using some logic on the backend, i.e., the backend would also use the secret key of some Pendulum funding account that is creating the Pendulum ephemeral account

[gianfra-t]

@TorstenStueber maybe we can already work on the trigger part by listening to a token transfer event targeting the ephemeral account.

This will work regardless of the implementation details of the Axelar part. WDYT?

[TorstenStueber]

Yes, do you just want to use polkadot.js to monitor incoming XCM messages for the ephemeral account?

[gianfra-t]

I tested listening to Transfer event from the tokens pallet. If we change it to listen to a Deposit event it should work with the XCM message.

[vadaynujra]

Is this ready to be merged to staging to be able to test or still requires more work @gianfra-t?

[gianfra-t]

It still requires some work. In fact, due to the overlapping changes with this one and #36, #40 I think it's best to merge those two first into staging, and then this one. I will start resolving those conflict ASAP locally.

[ebma]

@gianfra-t these changes are already included in the polygon prototype now, right? Should we merge them back into the v1 prototype with EURC? I think it's not really required anymore, assuming that the prototypes will be replaced by the 'real' vortex UI but correct me if I'm wrong and you would like to have this feature 6a available on the EURC prototype still @pendulum-chain/product.

[gianfra-t]

They are merged to polygon yes. In order to make the changes required exactly for this ticket, aimed at the old prototype, it is missing the modification such that the user sends tokens to the ephemeral. I have a local branch for continuing with this, if needed.

[ebma]

Okay cool, I will close this ticket now assuming that we don't need to add this to the EURC prototype. @pendulum-chain/product if you object, feel free to reopen this ticket.