ERC: Subscription Based ERC20 Token

Discussion thread for new EIP, Subscription based ERC20 Token, an extended form of EIP20

2 Likes

Suggest reading: Guidelines on How to write EIP. Do's and Don'ts including examples | by Anett | The Fellowship of Ethereum Magicians | Medium

EIP editors assign an EIP number (generally the PR number, but the decision is with the editors) (from: EIP-1: EIP Purpose and Guidelines), so you can’t just pick your own, e.g. ERC360

Apologies for that, I had read the guidelines, thought I could “propose” the number. Nevermind.

1 Like

Any views/comments on this proposal ?

link to the eip proposed

a working implementation on auto-debit subscription-based erc20 token - EIP 6932

Why use this over using approve with a subscription contract? This explanation should probably also appear in your Motivation section.

1 Like

sure, will add that too, here’s a quick glance -

if you use simple approve with a subscription contract, the contract will have to call again and again to fetch the subscription amount from the subscribers. in our EIP, this will not have to be the solution, it will be auto-debited and auto-credited without doing any single transaction. check the contracts for more info.

I’m not sure I follow (and I’ll be the first to admit my Solidity isn’t the best.) It looks like subscribe is supposed to lock an amount of tokens depending on the duration of the subscription?

It’ll lock the tokens of the recurring subscription amount, and not all the tokens at once. For example, if there’s a 20 tokens per month frequency, for a total period of 12 months, the contract will

  1. lock the first month amount
  2. then it will check for the 2nd month subscription amount,
  3. if the user holds the amount, it’ll be again locked (auto-debit) or,
  4. their subscription will be void/cancelled.

this will all happen behind the curtains, all the values will be updated auto, no transaction needed.

Does this happen as part of the first transaction? When does the 3rd month get locked/debited?

no, after the subscribe transaction, the contract will update the state of the account, and then it all depends on the subscription start time (info.start) and period elapsed (block.timestamp), all in a calculation

uint256 intervals = ( block.timestamp - info.start ) / info.frequency;
uint256 amount = info.amount * intervals;

for continuation of the subscription, the account must hold, greater than the amount tokens

the current balance will be the actual balance - subsription amount(s), when he transfers (normal transfer) the tokens, the actual balance gets updated