Make the relay automate executeCall right after a CallMessage event ?

[aymxdd]

When using XCalls, I found that the sendCallMessage -> <wait for CallMessage event> -> executeCall pattern can be very frustrating and a bit hostile to end-users, as you need to pay for one transaction, pay for BTP fees and then pay for a second transaction (costs can add up really quickly for ETH users). The problem is even worse when using fallbacks as you'll need a third transaction.

Another drawback is that on some networks, the block finality can take a very long time (looking at you ETH), making the user wait up to nearly 1 hour to execute one single cal + fallback round-trip.

Making users wait in front of a loading screen up to 1h or even 10-15 mins just to make a single cross-chain transaction seems a bit harsh and not very usable on a daily basis in my opinion.

I'm aware of the problems a self execute would cause to msg.sender, always pointing out to the relay contract tho.

But here are some solutions I thought of on the spot that might work to eliminate the problem:

• Make automated execution optional if you absolutely need the msg object (maybe a boolean in the CallService's sendCallMessage function arguments ?)
• Make every call execution automatic but include msg.sender in the payload automatically to be received on the destination chain

What's your opinion on this ? And for BTP devs, is that even possible to achieve ?

[mksong76]

@aymxdd Unfortunately, automatic execution is not eligible. The reason, why we let the user call "executeCall" is described in the wiki page XCall for arbitrary message delivery.