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.
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?
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.
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.
why uint64 for duration? Why limit not uint256? Seems like the flexibility is worth it.
after thinking about it a bit, all the interface really needs is isExpired().
The more methods, the more assumptions. On one end of the spectrum is just an interface determining validity, another is completely prescribing how subscriptions are done.
A middle ground is likely to leave a lot of people rolling their own solution.
What value is unlocked by having a standard for this? Not all subscriptions are the same today outside of Ethereum. The challenge isn’t in the technology but in the use cases.
I wonder what subscription-gateway services exist today? Mainly things like pay pal, etc.
The core value I’m not certain is in managing the subscription as much as it is enabling recurring payments. Having a solid standard for that brings wallets and thus users onboard to it.
I tend to agree with @aram that it could be kept even simpler by providing the read only interface to enable more flexibility with implementations.
Comments on tiers, auto-renewals and expected behaviours of NFTs are all important for implementation but less so at the interface level I would say. At least for a first subscription-based interface.
Loving the work, keep it up and let us know if you need any help.
This seems like a popular proposal, and something we have been thinking about at Verida for enabling streaming payments for storage node infrastructure providers.
