-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add EIP: Subscription-Based Token #6933
Conversation
File
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Reviewers Have Approved; Performing Automatic Merge...
Head branch was pushed to by a user without write access
@abcoathup will you share an update on this ? |
You need to add a rationale and security considerations section. Then you will need an EIP editor to review. |
The commit 9dad1cf (as a parent of e0f2e86) contains errors. |
https://github.com/360core/eip-6932 working implementation of eip-6932 |
|
||
## Specification | ||
|
||
The Subscription Token implements an interface following the guidelines defined in [ERC-1337](./eip-1337.md), ensuring consistency and interoperability across different implementations. Key features include: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mentioning ERC-1337 creates an implicit dependency between your proposal and that one. There's nothing wrong with doing so, if it's intentional, but I want to point it out because your proposal won't be able to advance past the status of ERC-1337 (so you'd be stuck in draft.)
We enforce this rule because the author of ERC-1337 could completely change the contents of their proposal, making yours nonsensical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I will minimize this
#### subscribers | ||
|
||
subscribers list for the subscription | ||
|
||
#### subscriptionInfo | ||
|
||
struct containing metadata of the subscription, ex, `subscriptionID`, `subscriptionName`, `subscriptionDesc` and `subscriptionTandC`, and many more fields if reqd. | ||
|
||
#### subscriptionFee | ||
|
||
the fee amount for the subcription | ||
|
||
#### subscriptionFrequency | ||
|
||
frequency of subscription, interval at which the `subscriptionFee` will be charged. | ||
|
||
#### subscribe | ||
|
||
function to subscribe toh the subscription | ||
|
||
#### unsubscribe | ||
|
||
revoke subscription |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The content here is a bit light, even for a draft. After reading, I don't really have a good idea of what these entities are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add more details to this
/// @return the address at index `idx` of subscribers | ||
function subscribers(uint idx) external view returns (address); | ||
|
||
/// @dev can be extended accorging to the requirements |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notes like this don't really belong in a standard. You should completely define the interface, with formal ways to extend it if necessary.
The introduction of the Subscription Token EIP addresses several critical aspects of the Ethereum ecosystem, providing a rationale for its adoption and implementation. | ||
|
||
Traditional subscription models often require users to manually initiate recurring payments, leading to inconvenience and potential disruptions in service delivery. By establishing a Subscription Token standard, users can authorize automatic deductions from their balances at predefined intervals. This automation simplifies the subscription management process, ensuring uninterrupted access to subscribed services without the need for repetitive manual actions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all reads more like it belongs in the Motivation section. The Rationale section should justify technical choices made within the EIP itself, while the Motivation justifies the EIP as a whole.
update to recommended description Co-authored-by: Sam Wilson <[email protected]>
Just checking if this is ready for re-review? |
Yes, just updating with the required changes, I'll push and tag you then |
I am closing this pull request because we are in the process of separating EIPs and ERCs into distinct repositories. Unfortunately, as far as we are aware, GitHub does not provide any tools to ease this migration, so every pull request will need to be re-opened manually. As this is a PR to create / modify an ERC, I will kindly ask you to redirect this to the new repository at ethereum/ERCs. We have prepared a guide to help with the process. If there is relevant history here, please link to this PR from the new pull request. On behalf of the EIP Editors, I apologize for this inconvenience. |
The subscription-based ERC-20 token extends the basic ERC-20 token standard with a subscribe and unsubscribe function, which allow users to subscribe or unsubscribe from the subscription service. The subscriptionFee and subscriptionFrequency variables define the cost and frequency of the subscription. The nextPaymentDate mapping keeps track of the next payment date for each subscriber.
This EIP also proposes adding renewSubscription functions to the token contract, that can be used by token holders to renew their subscription to a service or product that requires recurring payments in the form of the token.