Improving Web3 UX: Deferred Transaction Inclusion

Waiting for transaction inclusion doesn't have to mean, halt and wait.

Let's set the stage a bit...
I'm a liquidity provider (LP) for a DeFi protocol and receive LP tokens. I can stake those LP tokens and receive bonus rewards ("farming"), which is highly appealing and a common practice in DeFi.

This requires two transactions: an erc20 approval and approval. A staking interface might resemble the image below (figure 1).

Network conditions are important...

We can imagine that the baseFee is sitting around 40 GWEI, which is a bit high. This would place a simple erc20 approval in and around ~$3-$5, and the stake transaction might be around the same. So we're talking around $10 to jump into this farming position.

The Problem
Traditionally, if you were to be prompted to sign these transactions on an app, you would be first prompted to approve the transaction, and then you would wait for that transaction to be included in an upcoming block. Once the approval has been included, you repeat the process for the stake transaction (see figures 2 & 3).

Since the baseFee is high, I'm less inclined to perform the staking opportunity, so I either:

1. Wait for the baseFee to drop, or
2. Sign the approval at a lower BaseFee, then come back to the app at a later time when the baseFee drops.

A transaction is only submitted to the mempool once a transaction has been signed. As seen in figure 4, tx1 will be submitted to the mempool on block 1 and included in the blockchain on block 3. Once block 3 has been included, tx2 gets submitted to the mempool on block 4 and included in the chain on block 7.

In both of these cases, the user experience is dramatically impacted since I will need to navigate to your app multiple times and monitor gas prices. This leads to two scenarios:

1. Higher churn on your app
2. Users are exceeding their willingness to pay purely out of frustration

The Solution

Apps can implement a UI toggle called deferred transaction inclusion (figure 4), which will allow a user to sign both transactions without having the user need to wait for the previous transaction to be included in a block (figure 5 & 6).

Now, users can pay their ideal amount of gas without breaking the UI flow.

Referencing our previous example of transaction inclusion, we see differed transaction inclusion in action in Figure 7. Tx1 and Tx2 are both submitted to the mempool at the same time, on block 1. and are included in the blockchain a couple blocks later at blocks 11 & 12, respectively.

Further thoughts

EIP-4337 solves this by bundling operations together!

Yes, sort of, probably? Although most people are using EOAs and probably will continue to do so. I don't see that changing in the near term.

This could end horribly for token swaps!

Swaps might not be the best example. More concretely, it could be approve & stake LP tokens, a Gitcoin grant approve & send, or something unrelated to tokens altogether. There are many cases where this can be very applicable.