GeoDB. Technical discussion II

We continue with our technical discussion and now we will focus on the different ERC standards that we have considered to deploy our token.

Having decided to use Ethereum, there is a well-known and well-established option to issue a new token with which the risk of being wrong is minimal, the ERC-20.

More than 200,000 issued tokens and multiple manuals and tools reflect a reality, the ERC-20 is the de facto standard for issuing crypto assets in Ethereum.

In honor of the truth, for us the decision to opt for an ERC-20 was firm until a few months ago, and it was a decision we made practically at the same time that we understood that Ethereum is the DLT platform that offered us the most guarantees for the issuance of our token.

In any project where it’s necessary to use an Ethereum token, opting for an ERC-20 is a wise decision, as it implies a reduced risk and allows efforts to be focused on the rest of the elements of the solution.

But, as we have insinuated, in our case the choice of ERC-20 as the standard for our token was firm until a few months ago, and to this day, we could almost say that our token will not be an ERC-20 but an ERC-777.

What’s the reason?

Alternatives analysis

As indicated, ERC-20 offers many benefits, some clearer than others, but there is one that weighs more than the rest at the time of making the final decision, the peace of mind offered, both for the issuer and for its users or/and investors.

The ERC-20 is a widely known standard that has proven to fulfill its mission. Over time, some intrinsic problems to it have become apparent, but so far it has performed its job in an acceptable manner.

But by the simple passing of time, the consolidation of standards leads to their refinement and evolution, and after a while it’s common to find that the benefits of some of their successors begin to be undeniable. In these cases, at some point the risk of opting for a novel solution may be less than staying with the original solution.

The above reasoning led us to carry out an objective analysis of the different existing alternatives for the ERC-20 and in this post we summarize our conclusions in this regard.

Alternatives considered

Today there are multiple ERC standars for token emission. This blog post includes a brief description of the main ones and an excellent comparative infographic.

However, at the time of writing this blog post many of them cannot yet be considered as valid options and for us, the debate on the successor of the ERC-20 should focus on ERC-223 and ERC-777.

In this discussion we focus on reviewing (i) the main vulnerabilities of the ERC-20, and its two main potential successors, the standards (ii) ERC-223 and (iii) ERC-777.

Main vulnerabilities of ERC-20

Front-running approve/transferFrom

Currently ERC-20 has at least one front-running exploit that can occur by users’ mistake invoking the approve and transferFrom functions.

• approve allows you to assign another entity (user or contract) a permission to manage a number of yours tokens, N. This doesn’t imply that the tokens are transferred, it simply allows a third party to make this transaction.
• transferFrom allows the allowed entity to make the approve transaction effective.

What’s the vulnerability? Let’s see it with an example:

1. There are two users, Alice and Bob.
2. Alice needs to authorize Bob to transfer 10,000 tokens.
3. Alice uses the approve function but she made a mistake with the token units and instead of approving 10,000 tokens she has approved 100,000 tokens.
4. It’s not a problem. Alice corrects her mistake by invoking again the approve function with the correct amount and, problem solved! Or isn’t the problem solved?

What if, between steps 3 and 4, Bob has invoked the transferFrom function? In this case Bob has already transferred the 100,000 tokens approved by Alice, and in addition, he’ll be able to invoke the transferFrom function again to transfer an additional 10,000 tokens.

You may be thinking, ok, it’s a problem, but only if B is a malicious user. But what if Bob is really an automated service that receives your payment? a vending machine? or any other service that automatically triggers the transferFrom function when the approve function is called?

Transfer function

The second vulnerability has an idiomatic nature and depends on the user’s knowledge of Ethereum’s DLT.

To operate with a smart contract using an ERC-20 it’s often necessary to transfer some tokens to the smart contract that provides a certain functionality. Simple, isn’t it? We make a transfer to the contract address using the transfer function and nothing else to do.

What’s the problem? The smart contract cannot detect this transfer and therefore it cannot assign you the tokens transferred. To avoid this problem, the approve and transferFrom functions described above are used.

ERC-223

ERC-223 is a redesign of ERC-20 with limited backward compatibility with ERC-20 that includes additional security checks to prevent loss of assets by mistake. To do the above, it removes the approve and transferFrom functions and proposes a revision of the functionality of the transfer function.

Thus, the standard proposes that the transfer function must perform checks on the destination address, first checking the type of entity that will receive the transaction (user or smart contract) and if it’s a contract, checking whether it implements the tokenFallback function or not.

Technically, ERC-223 is a simplification of ERC-20 that moves the complexity of transaction management to the smart contract developer’s side, offering greater security and simplicity to users and UI developers.

Speaking of backward compatibility with the ERC-20, as mentioned above, this is limited. On the one hand, the elimination of approve and transferFrom functions prevents their compatibility with all the tools and smart contracts already deployed that make use of them. But on the other hand, usually the user wallets available to operate with ERC-20 tokens don’t make use of these functions, so in such a case, compatibility is guaranteed.

ERC-223 is currently being discussed as EIP (Ethereum Improvement Proposal) and it doesn’t appear to be readed to be used in production yet. Its GitHub repository isn’t very active and there are certain critical vulnerabilities that need to be fixed.

ERC-777

The ERC-777 standard focuses on adoption and usability. It’s a more complex standard, which implies a higher risk of future vulnerabilities.

The standard isn’t backward compatible with ERC-20 by default, but it can be (the functions of ERC-777 and ERC-20 are orthogonal) and it’s recommended that it be in order to accelerate its adoption. However, incorporating these functions leads to the vulnerability mentioned for the ERC-20, so there is some discussion in the community about it.

Among its advantages, we can highlight things like the following:

• Implements the mint and burn functions, defined in ERC-20 but without functionality in it.
• Implements an optional control to prevent funds from being blocked / lost due to user error.
• Simplifies the use of the transferFrom function, requiring fewer operations and consuming less gas.
• Allows users to reject incoming tokens from a blacklisted address.

It should be noted that the ERC-777 depends on another standard, the ERC-1820. The latter deploys a registry on Ethereum that allows to validate that the destination and source of token transfers have associated functions according to the functionalities of ERC-777 and other standards. But depending on another standard has three direct consequences, i) new potential vulnerabilities, ii) dependence on a third parties and iii) higher operational costs.

For us, today, ERC-777 is the only valid alternative to ERC-20. It was completed on May 7th, 2019, and open-zeppelin has even released an audited implementation backwards compatible with ERC-20.

Currently a small number of entities are making proposals based on it, Aragon being one of them, and so far, there have been no incidents reported.

And the winner is…

From the standards for the issuance of fungible assets in Ethereum we’ve focused on the ERC-20 as the best known, ERC-223 as evolution of it and ERC-777, much more novel and complete than ERC-20 but more complex.

Given the current state of the ERC-223 standard, we have decided to exclude it and focus our decision between the ERC-20 and the ERC-777.

A few months ago our decision for the first one was a firm decision, but recent events regarding ERC-777 such as the audited and backward compatible implementation with ERC-20 released by open-zeppelin have led us to rethink the standard to be used.

We have implementations for our token in both standards and we’re testing and reflecting on the pros and cons of choosing one or the other.

So, which one’s the one? We’ll tell you in a few days! Until then, be happy and stay tuned ;)