Hi I’m Madhav Aggarwal a member of the Tezos India Fellowship and currently an undergrad software engineer. I’m a blockchain enthusiast and have been working on De-Fi projects extensively. Recently I got selected for Tezos India Fellowship amongst 10 other students from the country. It was a unique opportunity for me to contribute to the Tezos Ecosystem and interact with developers from around the globe. I was guided by mentors in this amazing journey. The Tezos Ecosystem introduced me to a plethora of new ideas and I decided to work on the idea of creating a subscription token after a brief interaction with @MikeRadin from Cryptonomic.
CONCEPT:
The concept is to enable replay-able transactions; users sign a concatenated bytes hash that is composed of the input data needed to execute the transaction. This data is stored off chain by the recipient of the payment and is transmitted to the customers smart contract for execution alongside a provided signature.
So to make this easier to understand I’ll like to do a walkthrough of the Tezos Subscription Token. In simple words it’s a token subscription system.
WALKTHROUGH & FEATURES:
The publisher or service provider builds a contract by setting a couple of parameters and then subscribers sign these parameters and then allow tokens to follow. Lets go ahead and set a contract that says the subscriber will send a WasteToken( Local Dapp Token) every 60 seconds and add a gas price of 5 cents.
What this essentially means is that they will send me a buck total but 0.05 of that will go to the desktop miners. There are essentially two tricks to making this token subscription model work and one of those tricks is the replay nonce which in a meta-transaction essentially means that you can replay a transaction.
Now since the contract is deployed the service provider can grab the generated url and share it with the subscribers. He can post it on his website or add it to his publication.
So let us now suppose that an account is the subscriber and he/she wants to subscribe to the service. He puts in the URL which redirects him to the Token Subscription website. You’re going to be sending, to the address mentioned here the token WasteToken every 60 seconds.
Once he signs this with Tezbridge an off-chain meta transaction is triggered which describes that x amount of tokens should move and that this transaction should replay at the given interval. This thus goes to the meta transaction layer. Now this incentivised by the 5 cents that we sent will help the service. Now here comes the second trick. We use the approval function of FA1.2 as a play/pause button on the subscription. Thus once approved we trust the platform to push through the specified amount of tokens. There are no third party accounts over here which handle the funds. It is just the contract which is handling these funds and you can look at the contract and figure out what’s happening.
This is all open source and is exactly similar to the EIP 1337 model. Now once our approval goes through we should see tokens come over here. We can also view our transactions on carthagenet, the tokens move from one account to another on this subscription. So, you can see the effect live. Thus every minute you should see a transaction automatically going through. We can check this on TzStats.
There is also a feature to cancel the subscription anytime. This keeps the customers happy with a proper time-tested model. This can be integrated with the Quadratic Funding project to allow users to make subscription payments.
So there is another model which exists. Here I will allow the people to send me any token. This is a take-anything model where i set a contract to receive any sort of currency based on the subscribers choice. Which is basically an open-ended subscription. So instead of setting WasteToken I’m going to set “ANY” as my choice of currency over here. Now anyone who clicks the link we’ve added will be redirected to the portal where they can sign and pay. So basically if i put this URL on my website anybody can come along and send money in any currency that he wants. I’ve also given an option for inserting the email ID. Thus we can kind of follow the portal as we get updates.
USE-CASE:
Merchants who accept credit-cards do so by storing a token that is retrieved from a third-party processor (stripe, paypal, etc), this token is used to grant access to pull payment from the cx’s credit card provider and move funds to the merchant account. Having users sign input data acts in a similar fashion and enables that merchant to store the signature of the concatenated bytes hash and input data used to generate the hash and pass them off to the contract holding the subscription logic, thus enabling a workflow that is similar to what exists in the present-day legacy web.
I would like to get the views of the community regarding the implementation of this Model. Any improvements or feedback will be highly appreciated.
You can check out my work over here https://github.com/madhavaggar/subscription-token.
I would like to thank @FFF from the SmartPy community, @ClaudeBarde for helping me out with Taquito and @OmMalviya, @AdityaGautam, @KapilAgarwal & @Dibyo for helping me out with frontend integration and deployment.
