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.
Thanks for the response, I addressed these concerns in the response above this. Let me know what you think!
I really like this idea. This is my first time looking at contracts outside of tutorials so I will explore the repo and help where I can.
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.
That’s a great idea @cygaar. What happens to the token ownership when the subscription has expired? What will ownerOf() return in this case for example?
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?
It’s really a good idea. I think it can be applied to many scenarios
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.
Unlock is a special case of this, because the Unlock NFT is usually just the subscription. However if you have NFTs that represent art, owning the NFT is the utility in many cases.