Let me think on the renew function - I think it makes sense to require a function of this nature since it’s a core part of being a subscription. I would be open to having a second renew function that takes in a data bytes parameter (similar to 721 having multiple safeTransferFrom functions).
This is a bit tricky because if a user doesn’t pay for their subscription then it’s by definition canceled. Even if you say a subscription can’t be canceled, you can’t force a user to pay.
I think this would be a good idea for an implementation, but I don’t think it’s necessary for a standard interface. I’ll think about it some more.
Hi everyone! Thanks for sharing this brilliant idea ! I am Wen, I based in Paris and I am building an NFT-based subscription/ NFT gated e-commerce platform using Unlock @julien51 for the creators, e-commerce and the local business.
I really do like the idea, what about considering a pause state, as sometimes you may want to take a holiday from a sub but not cancel, there might be a limit for how long you can pause but may encourage them to remain subscribed.
I believe that it is important to describe what users should expect from tokens implementing this.
For example, ERC721 implies that I have ownership over a token. (Of course there’s nothing preventing contracts from doing all types of things, including implementing backdoors that allow someone else to transfer my tokens, but there is an expected behaviour and anyone not following is considered shady.)
So, regarding subscriptions, what should users expect? That they loose ownership? That the token is destroyed? That some of the token utility is limited?
If it was up to me, I would propose that when a subscription expires, all approvals are canceled. What this means in practice is that I can no longer trade the token (make profit, which is exactly the occasion when a creator would collect royalties normally). It is still owned by me, I can transfer it to my vault, or an other wallet, but I can’t trade it until I renew my subscription.
Thanks @cygaar, I was recently developping a similar subscription NFT.
I think manual is right as we should renew when we need to.
Having an NFT means you have ownership. The decision should be left to each project to decide about ownership.
It is very simple and we already think it is a good idea. What is the main problem with this EIP?
good proposal. For subscription-based NFT, I feel the auto-renew is an important feature, which is not defined in the interface. You have an interface of “isRenewable” , why not add an “isAutoRenewable” interface?
This is a good point. In my mind, when a subscription expires, the user still owns the token, but the token should no longer have any utility. I don’t think the EIP should include anything about transferability after a token expires - that should be left to the implementation.
In the case of Unlock the ownerOf function will still return the owner however balanceOf returns only the number of non-expired NFT so that tools that mostly rely on this will “block” access by default.
I really like your idea @cygaar ! I’m working on a specification of SBT (EIP-5727). In EIP-5727, there is an extension used for token expiration. (e.g. some skill certifications are only valid for a period of time)
I think your proposal is a perfect fit for this. I’m considering to integrate EIP-5643 if it went to Final.