Taking Fees on the Front-End
The Ethereum Alarm Clock uses an inventive method of monetizing a protocol in a decentralized manner. As far as I know, it may be the first protocol to try out this approach.
All credit for thinking of this approach goes to Piper Merriam, who created the Alarm Clock in 2015 and imbued into the projects the central ideas which are still continued today in the 1.0.0 release.
The Ethereum Alarm Clock has a field termed the fee. The fee is separate from the bounty which gets paid to TimeNodes for execution of the call and is required. In contrast, the fee is optional at a protocol level and is only something which is set higher up in the pipeline in the UI layers.
In the BlockScheduler and TimestampScheduler contracts there is a field denoted the feeRecipient. The *Scheduler contracts can be viewed as convenience wrappers over the rest of the Ethereum Alarm Clock back-end contracts.
The core of the logic sits in the RequestFactory contract which is the singleton to the Ethereum Alarm Clock. It is what the entire execution market of TimeNodes will watch for the new scheduled transactions. There is no defined fee or feeRecipeint variables in the RequestFactory and there never will be.
Instead, the RequestFactory can be plugged into by many different instantiations of the *Scheduler contracts.
What this means is that a third party can come along and deploy their own *Scheduler “front-end” to the canonical Ethereum Alarm Clock backend and set the feeRecipient to themselves and still benefit from the entire market of TimeNodes.
Why would anyone use someone’s *Scheduler front-end instead of another?
The reason may be that for specific users it will be easier to use one *Scheduler over another.
Take for example a wallet which wants to include functionality to trustlessly schedule transactions finds it hard to justify putting in the effort to integrate the Ethereum Alarm Clock.
If this wallet has a lot of users already, some of which may use this wallet exclusively, they could potentially monetize inclusion of the Ethereum Alarm Clock protocol.
They would do this by deploying their own set of *Scheduler contracts setting the feeRecipient to themselves. They would then implement in the front end a small fee on top of the protocol.
Even though it will be charging a fee for something users could find for free elsewhere, users may still pay this fee due to many different factors with convenience being the biggest one.
This pattern is an experiment to see whether a decentralized incentivazation method can work for a permisionless protocol. I’m looking forward to see if it picks up.
