Hey @favo, In terms of this VIP is it not already possible to implement this given that it is an extension to ERC-721? What is stopping anyone from taking the ERC-5643 code and implementing it into their ERC-721? Do we need a separate standard for an extension to an existing standard that is already compatible on vechain?
Fair point. It raises the question of whether we should continue to have a parallel VIP for each ERC? Personally, having a mirror VIP for each ERC in my eyes adds unnecessary confusion and complexity.
I agree with this as well. The current VIPs are already creating a lot of confusion and in the end the majority is implementing ERC templates from OpenZeppelin instead of basing their development on a VIP.
It is also not a decision for me to generally reject ERCs as VIPs. I personally think that its not adding anything except work. And while I say that, I also want to repeat that retroactively paying benefits may be a better way to motivate activity than paying for ideas in a PR.
Retroactive funding of public goods, like optimism, is a very good approach. It works very well for public goods to keep teams that are delivering and providing a public service funded.
Our goal with the VIP funding is to generate ideas and improvements for the VechainThor blockchain which don’t necessarily fall into the public goods domain. A financial incentive, such as what we are seeking to provide, usually helps to gain some traction in terms of ideas and implementation.
As you suggest perhaps a retroactive model is an improvement that we could move towards in the future. This would place the responsibility and accountability of building on the individual / team instead of on vechain. Perhaps there is a place for both models to exist.
@brettski I have three other improvements in my mind that I wonder if they fit into your expectations of a VIP:
Allow (X)Nodes to be transferred to contracts. (X)Nodes are currently not documented as VIP but are part of the core.
Adjustments to the standard Node-API to provide different data access (txpool for example).
Standard to share VTHO generation without sharing VET access.
Would you think that one of those would be a valid Improvement Proposal?
The second is a Pull Request to the standard API, the first requires adjustments by the core team. The third a contract template like the ERCs.
The below is just personal opinion. There are many other reviewers on the VIP reviewers team.
Allow (X)Nodes to be transferred to contracts: This is an interesting idea and for me would qualify as a VIP as it is specific to vechain. I guess my question would be what would be the benefit / use case / purpose of having the tech team deliver this?
Adjustments to the standard Node-API: For me certainly this would be a VIP as it is specific to vechain as it would be extending the functionality offered by Thor.
Standard to share VTHO generation without sharing VET access: Again I think this would qualify for me as it is something unique to vechain given the dual token model.
If the VIPs are raised I guess it would stimulate a conversation in terms of use cases / benefits of each.
Its a bit different, I’d like to think of a solution where you can designate the receiver of your generated VTHO, so you do not lose control over your VET.
In such a scenario vechain.energy’s fee delegation service could be powered the VTHO generation of other users without sending VTHO there.
@libotony is the suggestion here that there would be a catalogue of ERCs which would identify whether a given ERC is compatible with the VechainThor blockchain or not. If a given ERC standard is compatible there is no need for a VIP. If a given ERC standard is not compatible with the VechainThor blockchain, and given enough demand, a VIP could be raised requesting an implementation of this standard. Have I understood you correctly?
You are right, I think we don’t need ERC replicas here if it keep the same content as EIP, especially since we might need to maintain the content sync with the original EIP.