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
2 Likes
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?
2 Likes
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.