VIP180 superset of ERC20

In the documentation for VIP 180, it is mentioned: “The VIP-180 Standard is a superset of the ERC20”. However, this is not fully true for the functions below:

  • function transfer(address _to, uint256 _value) public
  • function transferFrom(address _from, address _to, uint256 _value) public
  • function approve(address _spender, uint256 _value)

These functions according to Etherium’s EIP-20 documentation (provided on the link above from you) are as follows:

  • function transfer(address _to, uint256 _value) public returns (bool success)
  • function transferFrom(address _from, address _to, uint256 _value) public returns (bool success)
  • function approve(address _spender, uint256 _value) public returns (bool success)

VIP180 doesn’t look like a superset of EIP-20 if it doesn’t behave the same way EIP-20 does. It leads to discrepancies between chains. That is why I have proposed to change the above functions to make VIP180 a subset of ERC20.

Pull request for this: VIP-180 improvement by paulaamstutz · Pull Request #54 · vechain/VIPs · GitHub


Why change the standard instead of just using ERC-20 over VIP-180? Vechain is EVM compatible so ERC-20 can be used freely on chain.

The only difference between these functions is that ERC-20 returns a value whereas VIP-180 does not.

Perhaps the word “superset” is too strong a word. Could you suggest a different word?


The differences between these two sets of functions can have significant implications when dealing with multi-chain scenarios, especially in the context of cross-chain transactions or interoperability between different blockchain networks.

In a multi-chain environment:

  • When using functions without a return value:
    • It can be challenging to confirm the success or failure of a transaction on one chain when interacting with another chain. This might require complex reconciliation mechanisms.
    • Cross-chain transactions might involve multiple steps, and without immediate feedback, it can be difficult to ensure the entire process goes smoothly.
  • When using functions with a return value:
    • It becomes easier to implement cross-chain transaction verification because you can immediately check the success status of each transaction.
    • Applications can handle errors more gracefully and take appropriate actions in case of a failure.

In summary, when dealing with multi-chain scenarios, it is generally more convenient and safer to use functions with return values as they provide immediate feedback on the success or failure of a transaction. This can simplify cross-chain interactions and improve the reliability of token transfers and approvals.
And we have a multichain token, which will need to act the same in all the different chains it is deployed, but on Vecahin it doesn’t. Even the audit marks it as a discrepancy. So in my opinion it is not only a wording issue. However, if you prefer not to change the standard, then calling it a superset is the wrong way. I cannot really think of another word but it would be sad to have a standard not compatible with EVM based chains. It risks to decrease the number of people using when it comes to cross-chain cases, in my opinion.

1 Like

If the objective is to create a token that is possible of going multichain the recommendation would be to create a token using the ERC-20 instead of VIP-180. ERC-20 tokens are supported and can be created on Vechain.

1 Like

If I understand right, you are saying that for multichain tokens we cannot use VIP180 ?
Are there added benefits in keeping these functions without returning a value?

1 Like

Hey @paulaamstutz, my suggestion is that if your aim is to create a cross chain asset then use a standard that exists on the chains you want to have your asset exist on. If it is a fungible token the best option would be to use the ERC-20 standard as it already exists on the majority of chains and is the default fungible token standard.

I understand, thank you. But just so I understand better, are there added benefits in keeping these functions without returning a value for VIP180?

1 Like

It is just a different implementation. VIP-180 does not return a bool for these functions whereas ERC-20 does. So the functions are still useful to have for the VIP-180 standard they just don’t provide a return value. Which as you have pointed out is a difference when comparing both standards.

1 Like

The presence of VIP-240, Adopt erc standards by darrenvechain · Pull Request #65 · vechain/VIPs · GitHub, I feel closes out this VIP.

The main point of this VIP is make the VIP-180 standard more interoperable and aligned with ERC-20. Our recommendation is that developers working on the VechainThor blockchain who are creating fungible tokens should use the ERC-20 standard instead of the VIP-180 standard. The main reason being to ensure that the token is cross chain compatible and in favour of interoperability.