Reversible transaction standards on Ethereum: ERC-20R and ERC-721R

The immutability of blockchain transactions is both a blessing and a curse.

BAYC Phishing Network Attack. PolyNetwork Hacking. Harmony Bridge Hacking. Ronin theft case. $14 billion in cryptocurrencies will be stolen in 2021 alone. These - and many more - are all confirmed thefts, but there's no "undo button" (e.g., reversal of credit card payments), and not everyone has a Jump Crypto to save them when the need arises.

But what if there was a reversible type of token?

This is the question that several of our researchers at Stanford (Dan Boneh, Qinchen Wang, and I) have been trying to answer for the past few months. We designed opt-in token standards similar to ERC-20 and ERC-721, and supported reverse transactions (when there is enough evidence to support it), wrote a paper on them, and implemented some prototypes . We call these token standards ERC-20R and ERC-721R respectively.

Now, you might be thinking: Reversible tokens? Doesn't this defeat the purpose of blockchain? Actually no. It's not meant to replace ERC-20 tokens or make Ethereum reversible -- it just allows theft to be challenged, and possibly restored, for a short time after a transaction.

Note that transactions can only be frozen for a short period of time (say 3 days) before becoming irreversible. ERC-20R funds are irreversible most of the time.

reversibility in transactions

In a transaction, the exchange between two reversible tokens is instant; if one party requests a freeze, it is possible to recover funds from the other party regardless of whether the reversible time period has elapsed. However, it is possible to swap reversible tokens for irreversible tokens; in order to protect themselves from being reversed, transactions may only be finalized after the reversible time period. This means that reversible→irreversible swaps will have a delay until the funds are irreversible. So once the two main tokens become reversible, there is a lot of pressure on other tokens to become reversible as well.

Depending on the implementation, it may be possible to immediately liquidate assets whose reversible time periods have elapsed (e.g. liquidate assets you received 3 days ago). In this case, there would not be a need for a delay between your reversible and irreversible tokens.

working principle

process of reversing a transaction

Suppose an attacker steals funds from a victim. Funds may be further transferred to other addresses as shown in Figure 1 below. The following will happen:

1. The victim requests to freeze the stolen funds. The victim submits a freezing request to the governance contract, along with relevant evidence and some funds. The transaction in question must be recent (with a fixed reversible time period).

2. The judge accepts or rejects the freezing request. A decentralized group of judges votes on whether to freeze assets. The deliberation time is at most one or two days. If they deny the request, the process stops and victims lose their funds. If they accept the request, the governance contract will freeze the ERC-20R/ERC-721R contract.

3. Perform freeze. For NFTs, it just prevents NFTs from being transferred. For ERC-20R, it will track stolen funds and prohibit the transfer of these funds. Please note that as long as the account owner's balance is higher than the frozen amount, they can still conduct transactions with others.

4. Judgment. Both parties can then submit evidence to a decentralized group of judges. Ultimately, the judge makes a decision and then instructs the governance contract to call the reverse or rejectReverse function on the affected ERC-20R or ERC-721R contract. If rejectReverse is called, the freeze on the disputed asset is lifted. Trials can be lengthy, possibly lasting several weeks.

5. Reversal (if applicable). The reverse function sends frozen assets back to the victim.

Figure 1: Transaction Example Diagram

Tracking Stolen Funds

When assets are stolen, they are rarely in just one place. Attackers often transfer it from one account to another. In this case, an attacker could even monitor the mempool and move assets in a front-running transaction when they see a freeze request coming in. Our solution to avoid this is to perform a full on-chain freeze (and its computation) in a single transaction, so an attacker cannot "run past" the freeze.

But we can't just disable every account that touches these assets, so how do we decide which accounts to freeze? Fortunately, in the case of NFTs, freezing is very simple: just look up who currently owns the NFT, and freeze that account. However, the divisibility of the currency makes freezing ERC-20s more complicated. Those funds can be split among dozens of accounts, transferred to anonymous mixers like Tornado, or exchanged for another digital currency. If it goes through a lot of accounts, at least some of them are related to the hacker. But some accounts are likely innocent, or merchants providing legitimate services in exchange for payment. It is not always possible to correctly identify the culpability of each account. Therefore, we provide a default freeze procedure to track and lock stolen funds. Our algorithm ensures:

1. Assuming there is no destruction, there will be enough assets frozen to make up for the stolen amount. (Destroyed assets will be subtracted from the returned amount)

2. The funds in the account will only be frozen if there is a direct transaction with the thief

3. As far as the transaction graph is concerned, the running time complexity of the algorithm is reasonable

We discuss more algorithmic details in the paper .

Decentralized Judicial System

The more nebulous part of the puzzle concerns the "decentralized pool of judges". Who are these judges? How do they vote? How are they rewarded?

These are ultimately up to governance, who creates the ERC-20R/ERC-721R instance. In our paper, we explore how to deter judges from dishonesty and bribery, reward mechanisms, and more. We emphasize that judges cannot add transactions or arbitrarily modify the value of one's balance.