Single click transaction automation

[prayagd]

Context

For the polygon prototype - Bridge + XCM + Swap + Redeem + offramp all operations should happen on a single transaction signing that would be done on the Polygon network.

[prayagd]

@TorstenStueber @gianfra-t @ebma please fill in the technical details

[ebma]

I think filling in the technical details is not really possible before we have the results of #40 and #42.

[vadaynujra]

@ebma wouldn't the blocker here be the bridge research only? If this is about writing a script on Polygon to automate trxs thereafter, can we not already progress this?

[ebma]

But in order to know how to automate/simplify a process I would need to know what the process looks like. And this I do after #42. To be honest, I think #42 and this ticket should go hand in hand as ideally we already thought about automating the whole flow as much as possible when working on #42.

[gianfra-t]

This ticket would be the placeholder for the logic of the user signing and kicking all the axelar bridge transactions right? If that is the case then yes it is very dependent on #42.

I agree all this tasks should go together and already we see a potential difference to what was expected, it seems to be the case that we can only bridge axlUSDC and not USDC. Which means we need to also add a swap first. It may be that the user has to sign 2 or 3 times on the polygon side.

• 1 or 2 for swap
• 1 for approval of axlUSDC to be sent
• the actual sending (which if we use a "sending contract" it can be only one sign, otherwise it will be two more)

[TorstenStueber]

I don't think that there is a real place for this ticket here. The "automation" is just the general logic of the prototype and the different bits of automation will happen in different tickets. Let's look at the flow:

• user completes anchor flow (already done)
• Axelar flow (this is ticket #42)
  • swap USDC to axlUSDC
  • approve the Axelar gateway contract
  • initiate bridging (using Axelar Gateway contract)
  • pay gas (using the Axelar Gas Service contract)
  • Moonbeam flow: happens automatically through smart contract
• Pendulum flow (this is partly ticket #35)
  • requires creation of ephemeral account on Pendulum that we finance
• Stellar flow (already done)

The remaining part is possibly the creation of the Pendulum ephemeral account. We did not clearly define whether this is part of this ticket here or of #35 (@gianfra-t how do you treat this?)

[TorstenStueber]

I forgot one thing: we also need to find a way of how to have a one click experience in Polygon. Right now 4 transactions would need to be signed.

I guess that this means that we also need to introduce an ephemeral account on Polygon in the same fashion as for Pendulum and as for Stellar. Likewise, we could also implement a smart contract that does these four actions on behalf of the user.

[vadaynujra]

@TorstenStueber what's the decision criteria to choose between the 2 solutions? Can you share more information on the pros and cons based on security, complexity, cost (per transaction) and / or others?

Alternatively, would a simpler solution (than the 2 above) maybe reduce the signings from 4 to 3 or 2 (instead of one), and maybe we could work with that for the pmf?

[gianfra-t]

@TorstenStueber I am treating #35 mostly as part of this Polygon -> Pendulum phase. That would include creation of ephemeral, function to await for ephemeral to receive tokens.

[TorstenStueber]

@gianfra-t can you elaborate how creation of an ephemeral account on Polygon would be part of #35?

[gianfra-t]

Not of polygon, but of the ephemeral account in Pendulum. Regarding what you where saying here, I was treating #35 as the corresponding ticket to handle that part of the whole flow automation, but so far I haven't made any assumptions as of how this account will be funded. We discussed I think a back-end funding this account similar to the signing service?

[TorstenStueber]

Yes, as I suggested here.

[prayagd]

closing this as i expect this to be completed, feel free to reopen if not.