Add VIP: NFT Subscriptions

This VIP outlines a set of common methods for recurring and expirable subscriptions attached to NFTs. It is based on ERC-5643 and requires VIP-181.

Ownership of NFTs can be used to verify access to certain areas. With this VIP recurring payments can be verified during access verification.

One example is an on-going subscription for a dApp:

  • When payments are stopped, then access can be blocked while still providing access to past information using the NFT information.
  • When payment is restored, access can be restored with all past information attached to the NFT, including past payments.

PR: Add VIP for NFT Subscriptions by ifavo · Pull Request #51 · vechain/VIPs · GitHub

1 Like

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?

1 Like

I agree. Due 210, 181 and 180 being identical to ERC115/ERC721/ERC20 I was under the impression that other relevant ERCs are also expected.

1 Like

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.

1 Like

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.

1 Like

@brettski I have three other improvements in my mind that I wonder if they fit into your expectations of a VIP:

  1. Allow (X)Nodes to be transferred to contracts. (X)Nodes are currently not documented as VIP but are part of the core.
  2. Adjustments to the standard Node-API to provide different data access (txpool for example).
  3. 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.


Hey @favo

The below is just personal opinion. There are many other reviewers on the VIP reviewers team.

  1. 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?

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

  3. 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.


It’s a question worthy of further discussion.

Regarding the third point, is it something similar to
Add VIP: VET Custodian Contract Standard ?

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’s fee delegation service could be powered the VTHO generation of other users without sending VTHO there.

So in other words it is the ability to delegate your VTHO generation to an address other than the address holding the VET assets.

1 Like

@favo @brettski How about we create a special VIP listing compatible ERCs, this list could be on-demand.

How about approve and transferFrom workflow, this might not be ideal but at some point solves the issue.

@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.

1 Like