WIP - standard draft

standard.md

@@ -0,0 +1,72 @@
+---
+eip: <to be assigned>
+title: Subscriptions
+author: 
+
+* Kevin Owocki <kevin@gitcoin.co> (@owocki)
+* TODO - Others pls add your info here.
+
+discussions-to: [this github issue url](https://github.com/EthereumOpenSubscriptions/standard/issues) or [Gitcoin Slack](https://gitcoin.co/slack) in #proj-subscriptions channel
+status: Draft
+type: Interface
+category Interface
+created: 2018-xx-yy TODO
+requires ERC20
+replaces none
+---
+
+
+## Simple Summary
+
+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) because
+
+For a user:
+
+* you don't have to read a complex whitepaper to use a dapps utility (as opposed to utility tokens)
+* you don't have to understand the founder's vesting schedules
+* you can cancel anytime
+
+For a dapp founder:
+
+* since you know your subscriber numbers, churn numbers, conversion rate, you get consistent cash flow
+* you get to focus on making your customers happy (as opposed to having two actors: speculators & users)
+
+For these reasons, we think it's creating a standard way to do 'subscriptions' on Ethereum. 
+
+
+## Abstract
+
+TODO: A short (~200 word) description of the technical issue being addressed.
+
+## Motivation
+
+We 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.
+
+We also believe that creating momentum for Saas models in the Ethereum space is critical, and believe that the standard is a trojan horse for doing so.
+
+
+## Specification
+
+TODO
+
+
+## Rationale
+
+TODO: The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
+
+## Backwards Compatibility
+
+N/A
+
+## Test Cases
+
+
+TODO
+
+## Implementation
+
+TODO
+
+## Copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).