Add VIP: VET Custodian Contract Standard

VIPs
1

Link to Pull Request: Add VIP: VET Custodian Contract Standard #45

As VeChain grows in scale and embraces DeFi activities, there is an increasing need for a standardized and an example of the best practice for handling VTHO generated by VET holding up in a smart contract.

Ideally, it should be distrubuted back to users fairly according to the VET deposited in the smart contract. This process shall be automatic and decentralized. The calculation should be accurate.

This VIP serves as an implementation guideline (Information) for such a topic.

The code example referred to in the document is audited and deployed in the vVET (wrapped VET) project, which is on mainnet address 0x45429a2255e7248e57fce99e7239aed3f84b7a53.

Since deployment over 18 months ago, it has had zero glitches and zero downtime. Served over 800k transactions.

3 Likes
2

I really like this idea! VeRocket implemented this feature and I really loved it.
Like the idea to help out our builders with implementation guidelines to create similar features or even be creative with it!

image

3

@xiqing.chu as this is already deployed to mainnet and in use am I correct in saying that your proposal is seeking to make this an enshrined VIP standard?

A question in terms of the calculateVTHO what if the generation rate were to change? It appears that the generation rate is hardcoded. This would mean that the contract would be providing an incorrect generation rate compared to the “official” generation rate. How would this be managed? A new deployment of the contract? Which would mean that users of the contract would have to perhaps forcibly exit their stakers, deploy the new contract and reopen the staking process. This seems like a risk and cumbersome for the user of the VIP. Is there a way to avoid the hard coding of the calculatVTHO?

2 Likes
4

Thank you for your interest!

  • This VIP provides an implementation guideline (information) to the application level. Compared to Ethereum, this is an ERC proposal rather than an EIP.

  • Very good point on the immutable of calculateVTHO(), this function SHALL be updatable according to the environment changes. Eg. Providing a mechanism to adjust the parameter of growth rate.

  • Although rarely happening (need the change of whitepaper, the consideration of old stakeholders, consensus across the community, etc), the growth rate CAN be changed, your point is valid.

  • The question is by whom? Better if we could directly read it from “on-chain” so there is no “admin” role in the smart contract.

2 Likes
5

I think being able to read the generation rate from an on-chain source would be the ideal way. As you have pointed out this would remove the requirement to update the contract either through an “admin” role. I am not sure if this currently exists however. Perhaps an investigation is needed and / or perhaps a VIP is required if the generation rate is not available on-chain.

1 Like
6

Just a random thought. Can we use the prototype contracts to determine vtho generation?

function energy(address self, uint blockNumber) external view returns(uint256);

Then perhaps you can check the current balance of the contracts account vs a future blockNumber of Energy. Divide to get the rate?

2 Likes