Replay-able Transactions, EIP 1337 implementation on Tezos

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.


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.


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.


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

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.


I’m not sure I understand this from the description you’re giving. Could you work out an example in details? I’m not sure what you mean by “a subscription token”, or “desktop miners” or what the “generated url” is, or what the contract parameters are, etc.


Hi @murbard

This project can be described in 4 stages.

In the first part a Publisher/Subscription Creator creates and publishes his subscription. The subscription is a contract with certain parameters. These parameters are:

  1. Token Amount: The number of tokens which will transfer from one account to the other.
  2. Time Period: The time period after which the transfer takes place.
  3. To Address: The address to which the tokens are transferred to.
  4. Token Address: The address of the token which is going to be transferred.
  5. Gas Price: The amount transferred to the desktop miner(*) which is deducted from total transfer amount.

(*) Desktop Miner: The desktop miner is the off-chain script running which parses subscriptions, checks for the ones that are active and makes the transfer of tokens possible from one account to another. Thus a certain amount of fees is provided to the desktop miner to keep functioning and cover up for the Tez cost of executing transactions.

The Second Part of the platform includes a generated URL which has the contract address appended at the end. This URL can be shared by the publisher with his peers/Subscribers. This generated URL redirects subscribers directly to the Signing page where they can approve tokens which we will talk about. [ There is a QR Code as well as a script allowing publishers to put up this link on their personal websites/make sharing easier ]

The Third Part includes signing. Signing refers to the subscriber approving and thus becoming ready to send his/her tokens. This Signing is done by generating a HASH. After signing subscriber is redirected to the next part automatically.

The Final stage includes the Subscriber approving tokens. The ‘Approve’ function is used a play/pause button. Thus as an example consider that 10 tokens are to be transferred from A to B every 60 seconds. The subscriber now approves 40 tokens. This essentially means that 4 cycles will be executed ( 1 cycle every minute which transfers 10 tokens for 4 minutes) and Subscriber will be able to see the gradual change in his remaining balance and the Publisher can also check that his balance will have increased.
Once the transfer is done and the allowance tokens change to 0 the Subscription is in pause mode and more tokens can be approved to restart it again.

Hope this answers all your questions clearly! Would love to hear feedback from the community

1 Like