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

BAYC phishing. PolyNetwork attack. Harmony Bridge compromise. Ronin theft. $14 billion of crypto stolen in 2021 alone. These - and so many more - are undeniable thefts, but there’s no “undo button” (ex. credit card payment reversals), and not everyone has a Jump Crypto to bail them out if needed.

But what if there was a reversible type of token?

This is the question that a few of us at Stanford (Dan Boneh, Qinchen Wang, and I) have been working to answer over the past few months. We designed opt-in token standards that are siblings to ERC-20 and ERC-721 and support reversing transactions (when there is sufficient evidence to merit it), wrote a paper about them, and implemented some prototypes. We call these token standards ERC-20R and ERC-721R, respectively.

Now, you may be thinking: Reversible tokens? Doesn’t that just defeat the purpose of blockchain? Actually, no. It isn’t meant to replace ERC-20 tokens or make Ethereum reversible - it simply allows short time windows post-transaction for thefts to be contested and possibly restored.

Note that a transaction is only freezable for a short amount of time (say, 3 days) before it becomes irreversible. For most of their lifetime, ERC-20R funds are irreversible.

Reversibility in exchanges

In an exchange, swapping between two reversible tokens is instantaneous; if a freeze is requested on one side, it would be possible to get funds reversed from the other side, no matter whether the reversible time period has elapsed. However, exchanging a reversible token for a non-reversible token may; to protect themselves from reversals, the exchange might finalize the swap only after the reversible time window has elapsed. This would mean that reversible→non-reversible swaps would have delay until the funds are irreversible. Thus, once a couple major tokens add reversible versions of themselves, there is pressure on other tokens have reversible versions as well.

Depending on the implementation, it’s possible to immediately liquidate assets for which the reversible time period has passed (e.g. liquidate assets you received 3 days ago). In this case, there would not need to be a delay between your reversible tokens and non-reversible tokens.

Here’s how it works:

Suppose an attacker steals funds from a victim. The funds may be further moved to other addresses, such as in Figure 1 below. The following would happen:

1. Victim requests a freeze on the stolen funds. The victim posts a freeze request to a governance contract, along with the relevant evidence, and some stake. The contested transaction must be somewhat recent (there is a fixed reversible time period).

2. Judges accept or deny freeze request. A decentralized quorum of judges vote to freeze the assets or not. This deliberation period should take a day or two at most. If they reject the request, the process stops there and the victim loses their stake. If they accept the request, then the governance contract will call freeze on the ERC-20R/ERC-721R contract.

3. Execute freeze. For NFTs, it simply blocks the NFT from being transferred. For ERC-20R, it will trace down the stolen funds and disallow those funds to be transferred. Note that the account owner can still transact with others as long as their balance stays above the frozen amount. This process can become complicated, as I will explain in the next section.

4. Trial. Both sides can then present evidence to the decentralized set of judges. Eventually the judges reach a decision, at which point they instruct the governance contract to call either the reverse or rejectReverse functions on the impacted ERC-20R or ERC-721R contract. If rejectReverse is called, the freeze on the disputed assets is released. The trial may be lengthy, possibly taking several weeks.

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

Tracing stolen funds

When stolen, assets rarely simply sit in one place. The attacker often moves it hot-potato-style from one account to another. In this case, the attacker could even monitor the mempool and move the assets in a front-running transaction if they see a freeze request incoming. Our solution to avoid this scenario is by conducting the entire freeze (and its calculations) on-chain in one single transaction, so that the attacker can’t “outrun” the freeze.

But we can’t just disable every account that has touched the assets, so how do we decide what and who to freeze? If it’s an NFT, freezing is fortunately pretty simple: just see who currently owns the NFT, and freeze that account. However, the divisible nature of money makes freezing ERC-20s much more complicated. The funds could be split among dozens of accounts, thrown into an anonymity mixer like Tornado, or exchanged into another digital currency. If it’s goes through many accounts, at least some of those will be tied to the hacker. But some may very well be innocent, or merchants who provided a legit service in return for payment. It is impossible to always correctly discern the guiltiness of each account. Thus, we have provided a default freezing process for tracing and locking stolen funds. Our algorithm ensures that:

1. Assuming no burns, enough assets will be frozen to cover the theft amount. (burned assets are subtracted from the returned amount),

2. An account’s funds will only be frozen if there’s a direct flow of transactions from the theft, and

3. The algorithm runs in reasonable runtime complexity with respect to the transaction graph.

We discuss more details of the algorithm in the paper.

The decentralized judiciary system

The more ambiguous piece of this puzzle concerns the “decentralized quorum of judges.” Who are these judges? How do they vote? How do they get rewarded?

These logistics are ultimately up to the governance, a.k.a. whoever creates the instance of the ERC-20R/ERC-721R. In our paper, we explore how to discourage judge dishonest and bribery, reward mechanisms, and more. We stress that the judges cannot add transactions or arbitrarily modify the values of one’s balance.

Want to learn more?

In our paper, we discuss many more details, such as how to decrease the risk of judge dishonesty, implications for exchanges and mixers, related work, and in-depth explanations of the algorithm and implementation. If interested, we encourage you to take a look. Our hope is that this starts a discussion on token reversibility, and that some of you may find even better reversible solutions that help reduce the losses in the ecosystem.

https://arxiv.org/pdf/2208.00543.pdf