Programming a smart contract is one of many distinct programming paradigms one must adapt to in order to succeed. Similarly to MVC architecture for apps, Object-oriented programming, or any other design pattern, one must learn the individual quirks of creating a smart contract as a part of the learning process. At a fundamental level smart contracts work quite differently from other programs for one primary reason: smart contracts run on a global state machine. There are many implications to this, one of them being that every user of your contract accesses the same state. I set out on an adventure to crack a nut that is generally difficult in this design paradigm: task scheduling. This was largely inspired by the recent release of a task scheduler on Solana, which made me begin to think how this could be possible within ETH while remaining decentralized. The blockchain strandbeest gets its name from a moving sculpture by Theo Janssen. Using only the power of the wind it crawls itself along beaches in Europe.

For server backends and personal computers alike, task scheduling is a critically important feature. Having the ability to ensure certain processes are executed at some point in the future or on a regular schedule without the need for human intervention every time something needs to be done is one of the primary ways in which computers make our lives better. They can fetch our email, update our apps and even place orders for household goods without any need for human help.

On any standard linux system, task scheduling is handled by a program called cron. I have always enjoyed using cron for automation due to its elegant simplicity. Cron consists of two parts: the crontab, which is a text file where one lists the tasks to be done and their respective schedules, and the daemon that handles their execution. Cron is used everywhere and likely supports many of the applications you interact with on a regular basis. Replicating automation within smart contracts is a hugely important task but one that is presumably difficult to solve whilst remaining completely decentralized. Every piece of logic in a smart contract is an update to the global state of the blockchain executing it and each update to this global state in turn costs some amount of (base layer) tokens. Therefore execution environments for smart contracts are generally designed to revolve around a “push” system - things don’t update/change independently, by default an account needs to initiate transactions that occur within smart contract memory. Finding a workaround here could bring systems like Hal and Gelato fully on-chain and eliminate points of failure related to centralization. In my estimation the only way around this is to design a sort of perpetual motion machine, akin to a digital Strandbeest set in motion once and forever doomed to wander.

The design of an onchain strandbeest is simple in principle but must account for the rather complex economics of a self-sustaining process and contain a system for processing arbitrary function calls from multiple locations at once. The strandbeest will actually consist of two smart contracts that use a ping-pong / tick-tock series of transactions at regular intervals. Then at each tick or tock, the contracts will check their queue for anything that needs to be executed. Instructions should include the binary or json data that needs to be executed, along with a pointer to the proper location. This way, all that is needed is a “primer” transaction at deploytime to start the process and nothing more. Should the contracts run out of ETH execution will stop, so keeping everything well capitalized is the most important consideration.

The contracts will also need significant ETH in order to pay for tx execution. A tokenized system to reflect the capital needed is optimal. The function of a token here would be to give a user exposure to the capital behind the contracts that are handling execution and also access to a share of the protocol revenue. In terms of payments incoming, there are two options; either users pay for what they use or the system is collectivized and ETH is handled in one large pool. I a combination of the two is the ideal solution for two reasons: 1) users should bifurcate into patrons of the protocol’s execution itself and consumers of additional resources for each function call and 2) yield will be higher in this case and likely make the protocol more sustainable long term.

There are two primary participants within this system. Gas subsidizers and gas consumers. Gas subsidizers support the regular tick/tocking of the system with deposits of ETH while gas consumers pay ETH equivalent to:

(function_cost * execution_freq * execution_period) + fee

Most of this ETH is spent to keep the ticking going while the rest accrues to the subsidizers as yield. The GAS token is minted proportionally to the degree of subsidy a user is providing, but gas prices fluctuate over time. Therefore the staked token must rebase to remain in line with updated gas prices consumed from an oracle. The resultant token is essentially an index of the conditions of the network, measured by the length of time each user’s stake could support ticking if gas became fixed at that moment. It would also yield a return denominated in ETH passively from fees collected.

There are two main risks to a project like this in my estimation. The first issue is the rapid fluctuations in local gas prices that are relatively frequent on Ethereum. The contracts could have a failsafe mechanism to pause during certain high gas environments (likely >500 GWEI, which typically do not last very long) or just ingest a moving average of the price. Otherwise, under normal conditions as long as ETH liquidity in the smart contract is sufficient everything will run smoothly. Lockups would likely be the best way to ensure stability of liquidity. The second is that as demand falls (perhaps due to high gas) yield evaporates. This problem can be mitigated by a degree of token inflation.

Gelato.network is a similar system that enables execution of tasks automatically on Ethereum. This system has thus far been successful and is a pleasant product to make use of, with the added convenience of the ability to pay in arbitrary ERC20 tokens. However, Gelato is comprised at its core of a network of operators that are maintaining availability of RPC to queue and send transactions. I believe that choosing to make use of smart contracts (and thus the superior security of ETH L1) is ideal because network liveness is no longer a problem. Given the robustness of Gelato at this time, it is certainly unlikely for it to fail; however, the risk is still nonzero. Furthermore, philosophically making use of the strongest security available at all times should always be preferred.

Why use? As a subsidizer the opportunity to earn ETH yield without worrying about token downside exposure or IL is attractive (since one can always return the same quantity of ETH back). Additionally, unlike liquid staking, where yield is tied to ETH inflation, in this case yield is purely the result of demand (but could be bootstrapped with token emission) and denominated primarily in Ethereum tokens. As a consumer scheduling tasks is a helpful function. Today there are centralized solutions that do this (and one could certainly create a server themselves that facilitates this easily) but these sytems are not on-chain. Overtime centralized elements will fade away from systems that rely on blockchains because of the risks they introduce. Scheduling tasks is one of many systems that need to be brought out of the Babylon that is centralization.

Programming a smart contract is one of many distinct programming paradigms one must adapt to in order to succeed. Similarly to MVC architecture for apps, Object-oriented programming, or any other design pattern, one must learn the individual quirks of creating a smart contract as a part of the learning process. At a fundamental level smart contracts work quite differently from other programs for one primary reason: smart contracts run on a global state machine. There are many implications to this, one of them being that every user of your contract accesses the same state. I set out on an adventure to crack a nut that is generally difficult in this design paradigm: task scheduling. This was largely inspired by the recent release of a task scheduler on Solana, which made me begin to think how this could be possible within ETH while remaining decentralized. The blockchain strandbeest gets its name from a moving sculpture by Theo Janssen. Using only the power of the wind it crawls itself along beaches in Europe.

For server backends and personal computers alike, task scheduling is a critically important feature. Having the ability to ensure certain processes are executed at some point in the future or on a regular schedule without the need for human intervention every time something needs to be done is one of the primary ways in which computers make our lives better. They can fetch our email, update our apps and even place orders for household goods without any need for human help.

On any standard linux system, task scheduling is handled by a program called cron. I have always enjoyed using cron for automation due to its elegant simplicity. Cron consists of two parts: the crontab, which is a text file where one lists the tasks to be done and their respective schedules, and the daemon that handles their execution. Cron is used everywhere and likely supports many of the applications you interact with on a regular basis. Replicating automation within smart contracts is a hugely important task but one that is presumably difficult to solve whilst remaining completely decentralized. Every piece of logic in a smart contract is an update to the global state of the blockchain executing it and each update to this global state in turn costs some amount of (base layer) tokens. Therefore execution environments for smart contracts are generally designed to revolve around a “push” system - things don’t update/change independently, by default an account needs to initiate transactions that occur within smart contract memory. Finding a workaround here could bring systems like Hal and Gelato fully on-chain and eliminate points of failure related to centralization. In my estimation the only way around this is to design a sort of perpetual motion machine, akin to a digital Strandbeest set in motion once and forever doomed to wander.

The design of an onchain strandbeest is simple in principle but must account for the rather complex economics of a self-sustaining process and contain a system for processing arbitrary function calls from multiple locations at once. The strandbeest will actually consist of two smart contracts that use a ping-pong / tick-tock series of transactions at regular intervals. Then at each tick or tock, the contracts will check their queue for anything that needs to be executed. Instructions should include the binary or json data that needs to be executed, along with a pointer to the proper location. This way, all that is needed is a “primer” transaction at deploytime to start the process and nothing more. Should the contracts run out of ETH execution will stop, so keeping everything well capitalized is the most important consideration.

The contracts will also need significant ETH in order to pay for tx execution. A tokenized system to reflect the capital needed is optimal. The function of a token here would be to give a user exposure to the capital behind the contracts that are handling execution and also access to a share of the protocol revenue. In terms of payments incoming, there are two options; either users pay for what they use or the system is collectivized and ETH is handled in one large pool. I a combination of the two is the ideal solution for two reasons: 1) users should bifurcate into patrons of the protocol’s execution itself and consumers of additional resources for each function call and 2) yield will be higher in this case and likely make the protocol more sustainable long term.

There are two primary participants within this system. Gas subsidizers and gas consumers. Gas subsidizers support the regular tick/tocking of the system with deposits of ETH while gas consumers pay ETH equivalent to:

(function_cost * execution_freq * execution_period) + fee

Most of this ETH is spent to keep the ticking going while the rest accrues to the subsidizers as yield. The GAS token is minted proportionally to the degree of subsidy a user is providing, but gas prices fluctuate over time. Therefore the staked token must rebase to remain in line with updated gas prices consumed from an oracle. The resultant token is essentially an index of the conditions of the network, measured by the length of time each user’s stake could support ticking if gas became fixed at that moment. It would also yield a return denominated in ETH passively from fees collected.

There are two main risks to a project like this in my estimation. The first issue is the rapid fluctuations in local gas prices that are relatively frequent on Ethereum. The contracts could have a failsafe mechanism to pause during certain high gas environments (likely >500 GWEI, which typically do not last very long) or just ingest a moving average of the price. Otherwise, under normal conditions as long as ETH liquidity in the smart contract is sufficient everything will run smoothly. Lockups would likely be the best way to ensure stability of liquidity. The second is that as demand falls (perhaps due to high gas) yield evaporates. This problem can be mitigated by a degree of token inflation.

Gelato.network is a similar system that enables execution of tasks automatically on Ethereum. This system has thus far been successful and is a pleasant product to make use of, with the added convenience of the ability to pay in arbitrary ERC20 tokens. However, Gelato is comprised at its core of a network of operators that are maintaining availability of RPC to queue and send transactions. I believe that choosing to make use of smart contracts (and thus the superior security of ETH L1) is ideal because network liveness is no longer a problem. Given the robustness of Gelato at this time, it is certainly unlikely for it to fail; however, the risk is still nonzero. Furthermore, philosophically making use of the strongest security available at all times should always be preferred.

Why use? As a subsidizer the opportunity to earn ETH yield without worrying about token downside exposure or IL is attractive (since one can always return the same quantity of ETH back). Additionally, unlike liquid staking, where yield is tied to ETH inflation, in this case yield is purely the result of demand (but could be bootstrapped with token emission) and denominated primarily in Ethereum tokens. As a consumer scheduling tasks is a helpful function. Today there are centralized solutions that do this (and one could certainly create a server themselves that facilitates this easily) but these sytems are not on-chain. Overtime centralized elements will fade away from systems that rely on blockchains because of the risks they introduce. Scheduling tasks is one of many systems that need to be brought out of the Babylon that is centralization.