# Add VIP: VET Custodian Contract Standard

**URL:** <https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44>\
**Category:** VIPs\
**Created:** [August 31, 2023, 4:54am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44 "2023-08-31T04:54:10Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![xiqing.chu](https://dub1.discourse-cdn.com/flex017/user_avatar/vechain.discourse.group/xiqing.chu/32/16_2.png) [@xiqing.chu](https://vechain.discourse.group/u/xiqing.chu)\
**Post date:** [August 31, 2023, 4:54am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/1 "2023-08-31T04:54:10Z")

</div>

Link to Pull Request: [Add VIP: VET Custodian Contract Standard #45](https://github.com/vechain/VIPs/pull/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.

---

<div class="post-metadata">

**Author:** ![VetMaik](https://dub1.discourse-cdn.com/flex017/user_avatar/vechain.discourse.group/vetmaik/32/14_2.png) [@VetMaik](https://vechain.discourse.group/u/VetMaik)\
**Post date:** [August 31, 2023, 8:39am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/2 "2023-08-31T08:39:51Z")

</div>

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](https://europe1.discourse-cdn.com/flex017/uploads/vechain/original/1X/dc365b32ccf529e4ad78a92bb96c4ff67efefada.png)

---

<div class="post-metadata">

**Author:** ![brettski](https://avatars.discourse-cdn.com/v4/letter/b/dfb087/32.png) [@brettski](https://vechain.discourse.group/u/brettski)\
**Post date:** [September 1, 2023, 9:27am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/3 "2023-09-01T09:27:09Z")

</div>

@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`?

---

<div class="post-metadata">

**Author:** ![xiqing.chu](https://dub1.discourse-cdn.com/flex017/user_avatar/vechain.discourse.group/xiqing.chu/32/16_2.png) [@xiqing.chu](https://vechain.discourse.group/u/xiqing.chu)\
**Post date:** [September 2, 2023, 2:00am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/4 "2023-09-02T02:00:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![brettski](https://avatars.discourse-cdn.com/v4/letter/b/dfb087/32.png) [@brettski](https://vechain.discourse.group/u/brettski)\
**Post date:** [September 4, 2023, 8:35am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/5 "2023-09-04T08:35:30Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tom](https://dub1.discourse-cdn.com/flex017/user_avatar/vechain.discourse.group/tom/32/35_2.png) [@tom](https://vechain.discourse.group/u/tom)\
**Post date:** [November 25, 2023, 5:45am UTC](https://vechain.discourse.group/t/add-vip-vet-custodian-contract-standard/44/6 "2023-11-25T05:45:11Z")

</div>

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?
