3.37 Special Token Pitfalls

So far we have looked at different security aspects of ERC20 tokens let's now take a look at few other tokens that are nowhere as widely used as ERC20 tokens, but introduce some concepts that are interesting from a security perspective.

ERC1400 Addresses

One of such token standards is ERC1400. This token standard was driven by PolyMath and was related to the concept of security tokens (tokens that represent ownership in a financial security, and note that the security has nothing to do with the program or application security we are talking about).

This token standard introduced the notion of permissioned addresses, which could block transfers from certain addresses. This is interesting from a security perspective because, if those addresses are malicious or if they can be compromised, then it leads to a denial of service (DoS) risk where transfers to and from such addresses can be blocked. This is a risk that we need to keep in mind if our smart contract application ever has to deal with ERC1400 tokens.

ERC1400 Transfers

Related to the notion of permissioned addresses, ERC1400 also introduced the concept of forced transfers where there are trusted actors within the context of the standard that can perform unbounded transfers. These trusted actors can transfer arbitrary amounts of funds to whichever addresses that they choose. This introduces a transfer risk that needs to be kept in mind when dealing with such tokens.

ERC1644 Transfers

A related token standard to ERC1400 is ERC1644 that allows the concept of forced transfers that we just discussed. This is again in the context of a controller role, which is a trusted actor in this standard that is allowed to perform arbitrary transfers of funds to arbitrary addresses. The trusted actor, if malicious or compromised, can steal funds. In this ERC standard, there is a risk from the controller address that needs to be kept in mind.

ERC621 totalSupply()

ERC621 token standard allows a different way to control the total supply of tokens. In this standard, there is a notion of trusted actors who can change the total supply after the contract is deployed. This is allowed using the increaseSupply() and decreaseSupply() functions that are specified by the standard. This introduces what is known as a token supply risk, where the token supply of such tokens can be changed arbitrarily after the contract is deployed.

ERC884 Reissue

ERC884 is another token standard that introduces yet another interesting security aspect. In this case, this token standard introduces the notion of cancelling and re-issuing. What this means is that the standard defines actors known as token implementers who can cancel addresses in the context of a contract that implements the standard.

In that process, what these implementers do is that they move any tokens owned or held by those addresses to a new address while cancelling the older address. This, from a user's perspective, introduces token holding risk because if you are holding certain number of tokens in a particular address, then the token implementers could move those to a new address and cancel your existing address.

ERC884 Whitelisting

ERC884 also introduces the concept of whitelisting addresses, where a certain set of addresses may be whitelisted by a contract implementing the standard. Token transfers are allowed only to such whitelisted addresses and not to addresses that don't exist in this whitelist. This again, as you can imagine, is a token transfer risk because a user might want to transfer tokens to a particular address but, if that is not whitelisted, then that token transfer is not allowed