Is your Dapp displaying incorrect information to users? It probably is — through no fault of your own.
Since the start of the year, we have conducted more than 30 Dapp Transaction Usability Audits. Every Audit involves more than 50 unique quantitative metrics and qualitative evaluations. One surprising finding: we have yet to audit a Dapp that cleanly handles either Canceled or Sped Up transactions. Why?
Before we dive into the problems Canceled transactions cause and why most Dapps don't address them, let's first cover the basics. [Note: This post focuses on Canceled transactions. We'll cover the ins-and-outs of Sped Up transactions in a future post.]
On Ethereum, a Cancel transaction is an attempt to overwrite a currently pending transaction with a new transaction. It's important to note that Canceled transactions are a convention and not a standard. Typically, a Cancel transaction will have:
The core of the idea is that, since miners are incentivized to prioritize transactions with more gas, the cancel transaction should be confirmed before the original transaction – even though it entered the mempool later. In other words, Cancel transactions are kind of like probabilistic mulligans.
Many, but not all, Ethereum wallets can help you cancel a transaction. In the case of MetaMask, you must first find and click a pending transaction to show the transaction detail, and then click the Cancel button. Like this:
How to Cancel a transaction in MetaMask
While the Cancel function might seem somewhat buried, it turns out to be a commonly used feature among more sophisticated and engaged Dapp users. These users make a habit out of carefully monitoring their transactions and proactively managing gas costs.
Straightforward enough... right? Not so much.
A critical piece of the puzzle is missing when it comes to Cancel transactions: your Dapp. While a user will engage with your Dapp to start a transaction, any Cancel activity occurs between that user and his or her wallet. Effectively, you and your Dapp are out of the loop.
Can you spot the key differences in the fourth and fifth transactions in the illustration below?
A Canceled Transaction: Illustrated
While the nonces are the same, the second transaction has:
The first three are central to what makes a Cancel transaction a cancel. The fourth one, however, is a headache for you and your Dapp.
Because the original and the Cancel transaction have different hashes, and the fact that your Dapp was not part of creating the Cancel transaction, your Dapp has no mechanism to connect the dots. This typically results in a transaction that will always show as pending. Here’s an illustrative example captured from a Dapp that we recently audited:
The first transaction was Canceled — and is permanently shown as "Pending".
The first transaction was pending on Mainnet, but then was canceled and replaced by a new transaction. Because of this, the Dapp displays the status for a transaction that will never confirm nor fail. Instead, the original transaction will show as pending — permanently. Bummer.
As the Ethereum network grows, Canceled transactions are becoming increasingly common. So Dapps need to build a robust front-end that can handle these situations cleanly.
This post was co-authored by several members of the Blocknative team — Sean O'Connor, Chris Meisl, and Matt Cutler.
If you've encountered a Dapp that does a great job of handling Canceled transactions, please let us know.
This post was originally published on the Blocknative blog. If you're looking for an easy to use API to solve the Cancel transaction UX headache, visit Blocknative.com and sign up for your free account.