owocki commented 6 years ago

I am opening this ERC as a means of discussing (a) the merits and (b) the viability of creating a standard way of managing recurring payments on the blockchain, both (1) for tokens, and (2) for Eehereum.

Merit

Monthly subscriptions are a key monetization channel for legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web (especially when compared to ad/surveillance) based models. They are arguably more healthy than a token based economic system (depending upon the vesting model of the ICO).

For these reasons, I think it's worth talking about the viability of creating a standard way to do 'subscriptions' on Ethereum. I'm envisioning an

From UX standpoint, it would be pretty nice if you could manage all your ethereum-based SAAS subscriptions from one service like an on-chain keychain, if privacy was respected.

Viability

Opt in every month model

This is already viable if a service were to send an email (or other notification) to a user to every month sign a transaction.

But it creates a lot of churn in the subscriber base because the steps of

sending the email.
receiving the email
opening the email
signing a tx
broadcasting the tx

is a lot of friction for the user.

It is also suboptimal from a cash flow perspective from the business, because the trickle of exchange of a value to the user and revenue for the business requires each party to reaffirm their relationship every month.

In a world in which there are 100s of Ethereum based dapps, it would simply be untenable from an attention standpoint for a consumer to manage all of their subscriptions in this world.

Opt out model

For the above reasons, I think it's optimal for Ethereum to support opt out subscription models. I am defining an opt out subscription model as

User consents to having price worth of ETH (or tokens) withdrawn every time_period by service_address.
The user may remove consent at any time.
The owner of service_address may remove price worth of ETH/tokens every time_period. If those tokens are available and the users consent is active and its been at least time_period since last withdrawal, then the tx will be successful. If not it will throw().

Case Studies

Take the case study of Adobe Creative Cloud. Prior to 2013, you had to pay $1000 for creative suite, and it was a massive barrier to entry. Now you just pay $40 per month, and you can learn the software and continue to pay if you use it. And Adobe can manage their cash flow over time.

Or the case of Amazon Prime. For $80 per year, one can simply (1) not have to pay shipping for their goods (2) receive a ton of benefits related to their content. And now amazon can do revenue forecasts more accurately because they're managing a consistent voume of cash flow.

virtuous-cycle-of-the-saas-business-model-e1497454519597

Technical Viability

Right now, it is not technically viable to do opt out recurring subscriptions on the blockchain. The best workaround would be to present a user with an approve(x) where x = price * n, where price is the monthly price of the service and n is a number of months, and then call transfer(x/n) every month or so.

Until (and if) ETH becomes a token, it would not be viable to do this at all with ETH.

Proposal.

I am not at a point yet with this idea where I feel comfortable presenting an interface. A discussion on (a) merit should precede the discussion on viability and proposal design.

My only strongly held beliefs for the 'proposal' stage of this ERC at this point is

that subscription payments are a core piece of infrastructure for the Ethereum ecossytem and thereby should not be subject to the rent-seeking nature of any tokenized product (other than gas payments setup already active in the Ethereum protocol)
The system should be architected such that a subscription product can be managed in a completely trustless way. (i.e. no trusted intermediary in between the two parties).

👋 @owocki and the @gitcoinco team.

owocki commented 6 years ago

@kermankohli we missed you on the call! can you make the next one?

for everyone else on the thread, here are our notes from the first call: https://docs.google.com/document/d/1P1fhGAJS_IYubUUEHEmPpg2ltjMZy7PR5Ot8xuJRbS8/edit#

please email me (kevin@gitcoin.co) or join the https://gitcoin.co/slack if you are interested in being in the conversation. we have a subscriptions channel there that were all hanging out in

owocki commented 6 years ago

@owocki Just got the invite and turns out the event is 12am for me today (Sydney, Australia). Is there any way we could pull back the meeting 3 hours or reschedule it?

the only thing is that we have someone in europe on the call. ack timezones are a pain. let me see what i can do.. would love to have you on the next one @kermankohli

kermankohli commented 6 years ago

@androolloyd Hey man, sounds good! Unfortunately I couldn't make the call since it was 12am for me although would love to setup a meeting otherwise.

@owocki Ah sorry about being a pain for timezones - I can stay awake till 10:30pm and can get up by 5:30am (weekdays) in case that helps? Also only working part-time Mon-Wed so the other days are pretty flexible.

Josephrp commented 6 years ago

following the discussion assiduously & expect to support this through coinpanion soonest.

On Wed, May 2, 2018 at 1:02 PM, Kerman notifications@github.com wrote:

@androolloyd https://github.com/androolloyd Hey man, sounds good! Unfortunately I couldn't make the call since it was 12am for me although would love to setup a meeting otherwise.

@owocki https://github.com/owocki Ah sorry about being a pain for timezones - I can stay awake till 10:30pm and can get up by 5:30am (weekdays) in case that helps? Also only working part-time Mon-Wed so the other days are pretty flexible.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/948#issuecomment-385940826, or mute the thread https://github.com/notifications/unsubscribe-auth/ARXoQGAtesimFA58p5_Nw6KJzZAu4Wfqks5tuZJagaJpZM4S6OSD .

androolloyd commented 6 years ago

@Josephrp cool project

johngriffin commented 6 years ago

Hi everyone,

I’ve been following this discussion and thinking about this problem for a while. I recently wrote a blog post and some POC code on the separate but related topic of tokenizing SaaS licenses, and I previously founded a non-crypto SaaS company so I’m most interested in the SaaS use case and I tend to use Stripe as my benchmark from the fiat world.

I just wanted to summarise and clarify my understanding of a few things, picking up on some points in the conversation around the 8x paper.

Firstly, the 8x paper is great, kudos @kermankohli. I think that there are some aspects of it that should be supported by an open standard but not necessarily specified in the standard. These are things that I think still fully make sense to be part of a protocol like 8x, but that we should probably separate out. For example:

Use of Dai as the payment currency, we should probably define support for any ERC-20 token.
Use of the 8x token to reward processors, this could be done with any token / eth.
There should probably be some way for you to ensure you process your own payments if you wish, so you can still create standards-compliant subscriptions but white-list just yourself as the processor.
The 1% reward figure for payment processors. Based on some back-of-a-matchbox maths it seems this would need to increase in the case that a payment amount was less than $8. Assuming it costs 40k gas to do the transfer() and gas price is 3Gwei, that would cost $0.08 today. I guess that at a minimum we need a reward percentage with an absolute minimum.

@kermankohl you mention to @nieldlr here that you had a way to solve the gas cost problem. I'm not sure if I'm missing something big here, do you mean there's a way to reduce the cost below a transfer() call per subscriber each billing period?

@nieldlr in response to your extra question 4 above - I believe that the processor reward increases with time to disincentive the payment being processed early. In the paper it says that the game theory and mechanics around this haven't been fully fleshed out yet but I guess we could also put some time lock around the payment?

Anyway, this is a really great start! I hope to join the call next week and I'll ask join the slack as it may be easier to discuss over there.

kermankohli commented 6 years ago

@johngriffin Thanks for taking the time to read through it and writing all of that up!

Definitely. Already added support for this by adding a tokenAddress variable in the subscription struct. https://github.com/8x-protocol/8x-protocol/blob/master/contracts/VolumeSubscription.sol.
Processors are rewarded in whatever token is used for the transaction (mainly Dai in this case). 8x tokens are simply used for staking to claim a payment and governance.
That's a pretty cool idea - although what could be some use cases for it?

4 In addition to the 1% fee, there will also be a flat fee of ~ $0.10. Not exactly sure how this would vary over time but essentially businesses will pay for the gas fee, not processors or users.

With @nieldlr's method, essentially you have to use loops in order to do pay outs which means you run into gas cost issues very quickly. With 8x, when a processor executes a transaction the money is immediately transferred to the business. There isn't a need to do any kind of loops. But overall I don't think there is a way to reduce the cost below a transfer (unless you use pull based payments but there's still the issue of taking money out and paying to do that).

Let me know if you have any questions/comments on the above - keen to speak with you at the next call!

johngriffin commented 6 years ago

@kermankohli Hey! Thanks for clarifying those points.

My thinking was that the most basic version of a recurring payments standard should be implementable with no more actors than subscriber and provider. It shouldn't have to depend on a network of processors, and if there were such a network you may wish to opt-out. Hence my suggestion of being able to only white-list yourself as the processor for a subscription is effectively a way to do that.

kermankohli commented 6 years ago

Hey everyone,

Following on from this thread you can track progress of the 8x Protocol at:

Telegram: https://t.me/joinchat/AXlpZ1LUmBqu3ySXHVh8qA Website: http://8xprotocol.com/ Twitter: https://twitter.com/8x_Protocol

I'll also be doing daily vlogs for this at: https://www.youtube.com/playlist?list=PLdm5dK5Ob2TnSUKlcYj3XfCO-iS8SeEfb

johngriffin commented 6 years ago

Hi all,

@Davidkobro and I have started work on an implementation based on @sb777's spec. Doing this has raised a number of questions and decisions that need to be made. I’ve pushed the code in it’s current incomplete state here, at the moment the core functions createSubscription() and processPayment() are in a working state dealing with periodTypes of seconds only.

https://github.com/johngriffin/ERC948/blob/master/contracts/ERC948.sol

Discussion points

If we allow payeeAddress to be set by the subscriber when they createSubscription() we probably need the contract to contain a whitelist of valid payeeAddresses. Perhaps there other constraints on valid subscriptions that the payee might want to implement when deploying the contract - e.g. only certain tokens / amounts are valid.
What is the purpose of isToken in the signature for createSubscription() ? Surely all payments have to be in tokens rather than ether as you can't delegate authority for a contract to move ether from your wallet in future.
Should we allow externalSubId? It seems preferable for a unique ID to be generated by the contract, otherwise the caller of createSubscription may have to make multiple transactions in the case that their chosen Id already exists.
If a payment is not collected in one billing period then we allow this payment to be collected at a later date provided the subscription is still active. Added “active” flag to subscription struct to handle this. This means that when a payment is processed we increment the nextPaymentDate by one billing period only, rather than set it to now() + billingPeriod.
I propose that in createSubscription we set nextPaymentTime to _startTime. So _startTime will be the time that the first recurring payment is made. The amountInitial will be taken immediately as createSubscription is executed.
processPayment() will only process one payment for one subscription at a time. If there are multiple billing periods for which payments haven’t been processed on a given subscription, then a transaction will have to be made for each of them. Of course it is possible to make a more efficient way of collecting these but doesn’t need to be part of the spec.
Date math - the pipermeriam library looks good but it only deals with date units as points in time. It does not deal with time intervals or date maths. E.g. when we are on month 12 and we want to increment the nextPaymentTime by a month, it can’t tell us how to do this. I’m reluctant to implement a date/time math library so if anyone has any alternatives suggestions I’d love to know.

Scott - what’s the best way to collaborate on the spec? I guess I could make comments on the issue?

nathantr commented 6 years ago

Wanted to add thoughts to @johngriffin's points above, also have the same question @sb777 on best way to collaborate on the spec?

Agree that there's a deeper topic here around what variables a subscriber might want to set and be in control of when creating the subscription. Although the merchant initiates the creation, this is with data from the subscriber and so we should be cognizant of what power should remain with the subscriber.
ExternalSubId it would be great it if there was an option for it to be both generated automatically or to be set by the merchant. Most merchants will have their own unique reference generated from their own systems, or use a unique identifier generated by the protocol.
Regarding payments and billing periods, let's be clear there's subscriptions, which handle describing the nature of the customer relationship, billing, which handles indicating how a customer should be invoiced, and payment, which handles how a customer should pay. Each of these is a deep domain within themselves. We could take the stance that the protocol should allow full flexibility and let the merchant bill on any day and let the subscriber pay on any day, or we constrain it (as I think @johngriffin is suggesting?) and say the merchant can only bill at a certain time and the subscriber can only pay at a certain time.

I think this may be a deeper topic as well to delve into.

Finally as a more general comment on the spec, there is a pauseSubscription method but then how do you resume? There are many reasons to want to resume a paused Subscription e.g., subscriber goes on vacation etc.

kosecki123 commented 6 years ago

Date math - the pipermeriam library looks good but it only deals with date units as points in time. It does not deal with time intervals or date maths. E.g. when we are on month 12 and we want to increment the nextPaymentTime by a month, it can’t tell us how to do this. I’m reluctant to implement a date/time math library so if anyone has any alternatives suggestions I’d love to know.

@johngriffin I came accros this library https://github.com/bokkypoobah/BokkyPooBahsDateTimeLibrary from @bokkypoobah

owocki commented 6 years ago

hey everyone.. ( i mean this in the least shill-ey way possible ) the working group creating this standard is really starting to pick up steam...

if you want to join... there is a slakc channel here => https://gitcoin.co/slack -- msg me and ill invite you to it and here are our notes https://docs.google.com/document/d/1P1fhGAJS_IYubUUEHEmPpg2ltjMZy7PR5Ot8xuJRbS8/edit#

mosayeri commented 6 years ago

What are the advantage of a new token over designing a wallet that would send recurring payments at set periods? I'm thinking that this proposed token is advantageous for accounting and payment management of the service provider, how about the user?

sb777 commented 6 years ago

Awesome work @johngriffin and @Davidkobro!

If we allow payeeAddress to be set by the subscriber when they createSubscription() we probably need the contract to contain a whitelist of valid payeeAddresses.

Do you mean, set up before the call to createSubscription, to compare against, or afterwards to keep track of which address was set?

Perhaps there other constraints on valid subscriptions that the payee might want to implement when deploying the contract - e.g. only certain tokens / amounts are valid.

I think so. My instinct is to leave the implementation of this outside of the spec, and just revert().

What is the purpose of isToken in the signature for createSubscription() ? Surely all payments have to be in tokens rather than ether as you can't delegate authority for a contract to move ether from your wallet in future.

Sorry, this was not clear enough. Let me expand a bit on the thinking behind this.

The model we're proposing would allow ETH as well by essentially creating an "escrow" wallet contract for all your subscriptions, where the wallet contract itself holds the funds/tokens, which would enable it to send out both ether and tokens.

The subscriber contract needs a whitelist of addresses which can call the subscriber-side management functions. At minimum, this can be the owner/contract deployer. In Groundhog, we are allowing user to authorize multiple devices/wallets (hw wallet, browser extension, Groundhog mobile wallet, other mobile wallet). Other contracts could even be whitelisted depending on what functionality people want to introduce. But in general our thinking is leave that up to the implementer.

processPayment() will only process one payment for one subscription at a time. If there are multiple billing periods for which payments haven’t been processed on a given subscription, then a transaction will have to be made for each of them. Of course it is possible to make a more efficient way of collecting these but doesn’t need to be part of the spec.

This is an interesting point. There was some discussion of whether "outstanding due payments" should be all sent at once or pulled one at a time. I'm inclined to think that processPayment should behave like a call to a credit card or a bank account - always have a value parameter and pull only that value, success/fail -- but -- if there are further outstanding payment amounts, multiple/subsequent calls can be made until there is no more available/due.

One other thought - Since one of the use cases we are trying to enable is the iTunes/API model, where you can approve up to X amount, and make subsequent calls throughout the period as that balance is spent - I wonder if we should add a mode flag on subscriptions to indicate this subscription type, so that balances don't roll over by period.

For example, if I'm authorizing an iTunes style subscription for up to $20/month, I don't want unspent amount to roll over into the next period as available balance. Maybe an unspentRollover flag?

The reason this is needed is, if it's just a garden variety $20/month SaSS subscription, if for whatever reason the merchant calls the subscriber wallet for a $10 payment, it should then be able to call another subsequent $10 payment in order to bill the full due amount. The only other way to do it would be to not specify a billing amount in the call, and just have the contract send the entire amount that's due when processSubscription is called. Then to enable the iTunes model, a flag could be set for discretePayments in which case a value is required for processSubscription.

So if we want to enable both "whole amount" billing and "up to billing" for the two identified use cases, it seems that we need either unspentRollover or discretePayments as a flag when creating the subscription. (there may be better names for these variables.)

And to @nathantr's point about subscriptions vs payments, I wonder if the function should actually be called processPayment rather than processSubscription.

sb777 commented 6 years ago

Oh, and just to introduce myself to the people on the thread I haven't met yet, I'm Scott, one of the co-founders of The Groundhog Network, along with @androolloyd. We're building Groundhog to supercharge Ethereum e-commerce.

Introducing Groundhog: https://medium.com/groundhog-network/introducing-groundhog-a1099f98ae84

johngriffin commented 6 years ago

Hey, so following the last call and chat on slack I just wanted to put forward what I propose to be the most important topics that we need to agree on. There are lots of great ideas flying around but we need to decide what should and shouldn't be part of this standard in order that we can agree on the technical spec.

Why does this need to be an ERC standard?
Anyone can create and implement a smart contract that has this functionality, what is the advantage in defining a standard interface? Answering this question should help us to answer all the other questions about what should / shouldn’t be included in the standard.

I suggest the reason for this standard is interoperability - we want wallets to understand that you’re about to sign a recurring payment contract so that they can present you with a UI that summarises the agreement you’re about to enter into. As your wallet now knows you’ve entered into a subscription contract it can also provide appropriate UI for managing and cancelling your subscriptions in future.

Should the standard deal with ETH escrow or just ERC-20 token payments?

Option 1 - payments must be made with ERC-20 tokens. The tokens remain in the subscriber’s wallet until a valid payment is requested by the merchant. The contract then transfers tokens directly from the subscribers wallet to the merchant.
Option 2 - (copied from @sb777 's post above) - The model we're proposing would allow ETH as well by essentially creating an "escrow" wallet contract for all your subscriptions, where the wallet contract itself holds the funds/tokens, which would enable it to send out both ether and tokens. The subscriber contract needs a whitelist of addresses which can call the subscriber-side management functions. At minimum, this can be the owner/contract deployer. In Groundhog, we are allowing user to authorize multiple devices/wallets (hw wallet, browser extension, Groundhog mobile wallet, other mobile wallet). Other contracts could even be whitelisted depending on what functionality people want to introduce. But in general our thinking is leave that up to the implementer.

Rules around payments and billing periods As @nathantr pointed out above it’s important to define the terms “billing” and “payment”. So we have billing periods and then payments that can be “pulled” within those billing periods. When the subscription is created there is a maximum amount that can be pulled per billing period.

Do we want to support multiple payments being pulled per billing period, upto the maximum allowance? Or merchant can only pull one payment per billing period.
Do we want to support pulling payments for past billing periods that have already elapsed, like a roll-over? See unspentRollover flag as mentioned by @sb777.

nathantr commented 6 years ago

Some great points @johngriffin. I can't say I fully follow the options @sb777 is proposing for ETH vs ERC-20, but having a single wallet that holds all your subscriptions definitely sounds appealing. Half of the problem of subscriptions is simply keeping track and being in control of all of them.

Re: payments and billing periods. I think having a notion of billing period is necessary (this is the periodType in the proposed spec I presume), and then pulling multiple payments per billing period would allow you to service a broader range of use cases. E.g., usage. If I as the merchant charge 1 USD per GB of Storage, then I am allowed to charge you up to, say, $10 for 10 GB of Storage. At which point you would need either raise the "cap" or start a higher cap subscription relationship with me.

The unspentRollover question I would be less in favor simply because of the complexity it creates. It really, at least to me, seems to be a flag that favors more advanced usage based billing use cases, and not sure if in a standard we want to start tracking some notion of unspent "credits". It would be great if this is something the implementer could do, e.g. they could check for the unspent amount and then use that to alter the "limit" of the subscription in the subsequent period, without needing the standard to do so explicitly.

I'd be an advocate for keeping it simple, and saying you can pull any amount of payments you want in a certain period up to an authorized limit. But it's a use it or lose it type deal, and anything unused does not get rolled over into the next period.

owocki commented 6 years ago

Update: The group will be using this repo to collaborate on the EIP: https://github.com/EthereumOpenSubscriptions/standard

jbergq commented 6 years ago

Hello everyone,

Thanks for the interesting read, I very much agree that there should be a standard for this type of service. What do you think of adding a timeSubscribed variable to keep track of the time a customer has been subscribed? A lot of subscription services appreciate loyal customers and often reward long time subscribers. The reason block.timestamp - startTime isn't enough for keeping track of this is because of the pauseSubscription() function, which will create empty time slots that shouldn't be counted.

nathantr commented 6 years ago

@Bergqvisten welcome! I think while pause resume does tend to throw off the notion of how long you have been an active subscriber, it doesn't affect the fact you may have signed up, for example, for a 12 month subscription. As long as you know when the pause and resume happened you could then calculate the impact on the "active" subscription length.

Typically with pause/resume you might build in a parameter to automatically extend the subscription when you resume, if you know it. that might be nice @sb777

jbergq commented 6 years ago

Thanks @nathantr! You're right, that would totally work for a subscription plan with a specified length. I think the implementation I had in mind was a little bit different, hence the requirement for a total time subscribed.

I read about the problem of gas cost earlier in the thread. Is this something that has been solved to an acceptable degree yet?

kosecki123 commented 6 years ago

As an extension to @pipermerriam proposal, I think having definitions for functions to return the status of the subscription would be beneficial

isFunded() returns bool: returns true if there is currently enough funds (ETH or tokens, depending on implementation) available for provider to collect
availableFunds() returns uint256: returns the amount of ETH or tokens available for the provider

Major benefit would be an ability for subscription provider to monitor the current status of the subscription without using gas (for e.g by executing triggerPayment()). For the subsribee perspective would allow scenarios where 3rd party protocol can monitor and fill the subscription accounts for e.g keeping the funds to pay for next 1 or 2 months

nathantr commented 6 years ago

Completely agree with Piotr

On Thu, 21 Jun 2018 at 06:22, Piotr Kosiński notifications@github.com wrote:

As an extension to @pipermerriam https://github.com/pipermerriam proposal, I think having definitions for functions to return the status of the subscription would be beneficial

isFunded() returns bool: returns true if there is currently enough funds (ETH or tokens, depending on implementation) available for provider to collect

`availableFunds() returns uint256': returns the amount of ETH or tokens available for the provider

Major benefit would be an ability for subscription provider to monitor the current status of the subscription without using gas (for e.g by executing triggerPayment()). For the subsribee perspective would allow scenarios where 3rd party protocol can monitor and fill the subscription accounts for e.g keeping the funds to pay for next 1 or 2 months

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/948#issuecomment-399101366, or mute the thread https://github.com/notifications/unsubscribe-auth/ACLVyQP72HKgEL2VxcIZR3K1DaruCB4tks5t-54HgaJpZM4S6OSD .

-- Nathan Creswell m: (650) 2885351 e: nathantr@gmail.com li: https://www.linkedin.com/in/nathancreswell

owocki commented 6 years ago

Update from the working group: We are drafting the EIP at https://github.com/EthereumOpenSubscriptions/standard/issues/8 . All are welcome to contribute. Goal is to have this submitted by early August

PaulRBerg commented 6 years ago

Hi everyone,

I'm doing some research on state channels and fully decentralised, recurring payments, so it was pretty cool to read through all the ideas brainstormed here! Definitely a great initiative @owocki.

Static, time-based subscriptions totally make sense, but I want to challenge the underlying assumptions in https://github.com/EthereumOpenSubscriptions regarding dynamic pricing. Why would a company like AWS want to use ERC948 instead of asking the user to pay per unit? That is, when they consume 1MB on S3, they are charged $0.1 (arbitrarily set price). Thanks to Raiden, Liquidity & co, this will be possible in the future once the tech consolidates.

I acknowledge the fact that on state channels one has a balance they cannot go over (although there are proposals to remedy this), while on ERC948 they could be continuously charged from an address, allowing them to top up. This is handy for long-term subscriptions.

However, given low mental transaction costs, I posit that the advantages of pay-per-unit outweigh the disadvantages of billing at the end of the month.

owocki commented 6 years ago

@PaulRBerg good to meet you. wanna join our weekly call (thursday mornings) and nerd out about this?

PaulRBerg commented 6 years ago

Sure thing! Emailed you now.

Josephrp commented 6 years ago

there's a weekly call ? very much eager to listen in :-)

On Tue, Jul 17, 2018 at 11:31 PM, Paul Berg notifications@github.com wrote:

Sure thing! Emailed you now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/948#issuecomment-405734658, or mute the thread https://github.com/notifications/unsubscribe-auth/ARXoQE-5XY9bz5zZmWxwFYVz681G7lLpks5uHlekgaJpZM4S6OSD .

owocki commented 6 years ago

yes. contact @androolloyd for the weekly call.

we are all hanging out at gitcoin.co/slack in the #proj-subscriptions channel too

PaulRBerg commented 5 years ago

Just published the research I and @mmilton41 have been doing on Chronos, a protocol for continuous, recurring payments. Although it's tangent with the ideas expressed in this chat, the focus is instead on infinitesimally small payment intervals (minutes, hours, rather than months). We mentioned ERC948 and the projects working on it in our draft white paper.

Still many things left to cover (we're using Plasma), but aiming to start coding soon to test our assumptions. Feel free to join the discussion here:

https://ethresear.ch/t/chronos-a-quirky-application-proposal-for-plasma/2928

leonprou commented 5 years ago

I've had an idea that the subscription model can be used for crowdfunding. In some cases it's a better fit than the ICO.

For example, I want to create a service (a Dapp). I can sell subscriptions for the service to fund the development. Maybe even investors would buy subscriptions to the future service as an investment, to sell them later to customers for a higher price.

Looking at this use case subscriptions are like NFT's.

androolloyd commented 5 years ago

@leonprou you're going to really enjoy an upcoming post from Groundhog, we've been working on this model for a few months now.

jtakalai commented 5 years ago

I see this is already a fairly old thread. Has this idea been already discussed: Build (an ERC20) token that allows for "streaming transfer", that is, a stream of value at a set rate. It would perhaps be similar to time-locked cheques, only the time-lock is checked on every transfer (normal or "streaming" kind) so that tokens that "don't belong to you anymore" can't be transferred.

interface IERC20Streamable {
    function stream(address to, uint256 tokensPerSecond) external returns (bool);
}

Benefits:

a recurring payment could be implemented on top of it as a smart contract, no need for layer 2 solutions
it could be as precise as desired: pay per second; or if block.timestamp is considered bad, pay per block
it wouldn't need recurring transactions; only initiating the subscription and withdrawing revenues would incur gas costs
no need to lock up tokens up-front; they would be debited over time automatically (until account runs dry)
unopinionated and basic: recurring, volume, etc. subscriptions could be implemented on top of it

It would be straightforward to check if the account still can pay for its subscription(s). What happens after the account dries up would be outside the scope of the specification, but at least the vendors would have simple ways to follow if they're still getting paid. If the particular ERC20+streaming would be tied to a service with limited number of different types of subscriptions, the "end timestamp" of currently active subscriptions could be calculated and emitted upon each transfer. This would make it even simpler for vendors to follow if they're getting paid: instead of polling, they could listen to update events by the subscription ID.

Withdrawing could even be done so that existing approval functions are augmented to show tokens belonging to a vendor as approval from the ERC20 account, and vendor could then simply transferFrom their earnings so far any time they please. This would mean the minimal addition to the token API would be the one function stream that sets the volume of the flow of tokens. The flow could then be cut by calling stream(to, 0). Likely other functions for querying the transfer streams would also be useful to wallets that want to support this kind of model, though.

Implementation scope and challenges:

transfer, transferFrom, balanceOf need to be re-implemented to account for the streaming transfers, basically to set limits to what the account or anyone approved can transfer out. Perhaps simply re-implementing balanceOf would suffice.
each streaming transfer should only receive its correct portion when the account runs out of credit, so that there won't be a race to withdraw tokens by different vendors (in the subscription case). The seconds * tokensPerSecond tokens that were (conceptually) transferred before the account ran out of credit belong to their respective to addresses. In case the payer later tops up the account, then how tokens should be allocated from the intervening "defaulted" time, is up for discussion. Straightforward solution would be to pretend there was not "default" to begin with, and continue calculating the balances as before, but of course in practice the vendors may already have cut the service. Perhaps that could be left outside the specification.

If this idea sounds appealing to anyone, I could knock together a simple PoC implementation.

If this already has been discussed and/or implemented, I'd love to hear about it (please link to URL). If the functionality has been implemented already in another form, that's interesting too. I skimmed through the 8xprotocol white-paper, and it proposed an interesting layer 2 solution. I'm just wondering here if a simple (it's relative...) smart contract could also do.

EDIT: Chronos has an implementation of "token streams"

EDIT: @d10r mentioned their project Artis that implements token streams called Streems

d10r commented 5 years ago

@jtakalai yes, I've done a PoC a while ago, the code can be found here.
This was a first, unsafe implementation of the idea. I've since implemented a safe one (so I claim, yet to be proven) with the limitations described here. It will soon be published, together with a demo use case. We're also working on a Rust implementation for pwasm (which I've heard is going to somehow be merged with ewasm).

PS: Vitalik also seems to have discovered the topic: https://twitter.com/VitalikButerin/status/1093091291066294272?s=19

d10r commented 5 years ago

Follow up to my previous comment: Proposal for Streaming Token Standard with example implementations linked in Implementations section.

github-actions[bot] commented 2 years ago

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

github-actions[bot] commented 2 years ago

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

Josephrp commented 2 years ago

Dear Colleagues,

the end of an era, but not the end of this idea. Here's to hoping each of your's workarounds end up as a standard for this soon !

Warm Regards,

-Joseph.

On Sun, Jan 2, 2022 at 12:11 AM github-actions[bot] < @.***> wrote:

Closed #948 https://github.com/ethereum/EIPs/issues/948.

— Reply to this email directly, view it on GitHub https://github.com/ethereum/EIPs/issues/948#event-5832130372, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEK6QQELYYEDBG24BVNTURLUT6C3VANCNFSM4EXI4SBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

folego commented 8 months ago

I tried to find the status of this proposal on the ETH page https://eips.ethereum.org/all and I couldn't. So kept googling and I found this. Sad to see that is closed and no more in discussion. I don't understand how such good idea can't be on the queue to be implemented. Any chances to reopen this?

specialOne-coder commented 8 months ago

Hi eveyone, Largely inspired by this idea, I create Subs , a protocol for making recurring onchain payments that can have different uses cases such as subscriptions, DCA, recurring donations or others.

Website : https://subsprotocol.com/ Doc : https://subspro.gitbook.io/subs/introduction/overview Whitepaper : https://subsprotocol.com/assets/Subs_Protocol_Whitepaper-a15e8bea.pdf

Please, take a look, am open to discuss if needed. Best regards

nathantr commented 8 months ago

Hi eveyone, Largely inspired by this idea, I create Subs , a protocol for making recurring onchain payments that can have different uses cases such as subscriptions, DCA, recurring donations or others.

Website : https://subsprotocol.com/ Doc : https://subspro.gitbook.io/subs/introduction/overview Whitepaper : https://subsprotocol.com/assets/Subs_Protocol_Whitepaper-a15e8bea.pdf

Please, take a look, am open to discuss if needed. Best regards

@specialOne-coder This is absolutely incredible what you have created. Tried to reach out to you on Twitter but unsure if there is a better way to contact you?

livingrockrises commented 8 months ago

For the case of tokens, couldn't you do something similar to 0x, where you give an unlimited allowance to a smart contract which has clearly bounded functionality (to only allow withdrawals of amounts you approve, on a certain interval)?

Service deploys a smart contract that can withdraw tokens from users (or even better, it's a shared contract for all subscriptions). The contract could be audited to see that it will only withdraw amounts that the user approves

The user "approves" the contract for an unlimited allowance

The user calls the createSubscription() function, allowing price tokens to be withdrawn from them every time_period by service_address, until they cancel

Every month, the service_address calls withdrawSubscription(), which uses transferFrom() to collect the tokens that have been authorized

This would allow the user to authorize an ongoing subscription with one-time setup, and no need to escrow funds. Would this satisfy your requirements?

Doing this with ETH is probably harder, as there's nothing like the "approve" function that I'm aware of.

I think for eth or erc20 any subscription payments, this can be done with smart contract wallets for consumers and having special contracts aka SubscriptionModules enabled where service provider can pull payments

folego commented 8 months ago

For the case of tokens, couldn't you do something similar to 0x, where you give an unlimited allowance to a smart contract which has clearly bounded functionality (to only allow withdrawals of amounts you approve, on a certain interval)?

Service deploys a smart contract that can withdraw tokens from users (or even better, it's a shared contract for all subscriptions). The contract could be audited to see that it will only withdraw amounts that the user approves

The user "approves" the contract for an unlimited allowance

The user calls the createSubscription() function, allowing price tokens to be withdrawn from them every time_period by service_address, until they cancel

Every month, the service_address calls withdrawSubscription(), which uses transferFrom() to collect the tokens that have been authorized

This would allow the user to authorize an ongoing subscription with one-time setup, and no need to escrow funds. Would this satisfy your requirements? Doing this with ETH is probably harder, as there's nothing like the "approve" function that I'm aware of.

I think for eth or erc20 any subscription payments, this can be done with smart contract wallets for consumers and having special contracts aka SubscriptionModules enabled where service provider can pull payments

But in this case the user should create a new smart wallet right?

specialOne-coder commented 8 months ago

For the case of tokens, couldn't you do something similar to 0x, where you give an unlimited allowance to a smart contract which has clearly bounded functionality (to only allow withdrawals of amounts you approve, on a certain interval)?

Service deploys a smart contract that can withdraw tokens from users (or even better, it's a shared contract for all subscriptions). The contract could be audited to see that it will only withdraw amounts that the user approves

The user "approves" the contract for an unlimited allowance

The user calls the createSubscription() function, allowing price tokens to be withdrawn from them every time_period by service_address, until they cancel

Every month, the service_address calls withdrawSubscription(), which uses transferFrom() to collect the tokens that have been authorized

This would allow the user to authorize an ongoing subscription with one-time setup, and no need to escrow funds. Would this satisfy your requirements? Doing this with ETH is probably harder, as there's nothing like the "approve" function that I'm aware of.

I think for eth or erc20 any subscription payments, this can be done with smart contract wallets for consumers and having special contracts aka SubscriptionModules enabled where service provider can pull payments

For eth yes, but for ERC-20, smart wallets is not needed, just approval can do the job. And I don't think anyone is keen on paying for subscriptions with eth, unless it's a specific use case, like paying off a debt every month.

filmakarov commented 8 months ago

For eth yes, but for ERC-20, smart wallets is not needed, just approval can do the job.

Unlimited approvals to a third-party contract can't be good practice tbh. Making this via Modular SCW with a subscription module would be much safer

ethereum / EIPs

Recurring Subscription Models are a Good Thing and should be viable on Ethereum (Merit + Architecture ERC) #948

Merit

Viability

Opt in every month model

Opt out model

Case Studies

Technical Viability

Proposal.