‘Smart contracts’ is a misnomer. Despite its name, smart contracts on Ethereum are not self-executing digital agreements. Smart contract code only run when triggered by an external account. In other words, you need an external process to trigger the smart contract.

In this article, we’ll build a solution to this problem. You’ll learn:

• Why we need off-chain smart contract automation
• Use cases for smart contract automation
• How to deploy serverless functions with the Serverless framework

Finally, we’ll go through serverless-ethers, a fully-functional smart contract automation service that you can run and deploy out-of-the box. You can use this project as a base for building custom smart contract automation that fit your needs.

The serverless-ethers

** sample application is open source and available on Github.** Just clone and hit deploy!

Read on to learn why we need automation and how it works.

The Problem: Smart contracts are not self-executing

Imagine that we want to implement a smart contract with a function that should be automatically executed every 1 hour. ⏳⚙️

How can you accomplish this?

You can’t. This is not possible with plain Solidity smart contracts. Despite its name, ‘smart’ contracts in Ethereum are not self-executing. You need an external source (either human or machine) to call the smart contract and execute its code.

The most a contract can do is enforce a 1-hour interval between executions, for example:

function runMe() public {
  require(block.timestamp >= lastTriggeredAt + 1 hour);
  ...
}

The above require() statement ensures that there is at least an hour in between executions. Otherwise, the transaction reverts.

However, somebody still needs to call the smart contract for the code to run in the first place.

An Aside on Self-Execution

Technically, it is possible to use function modifiers to automatically execute certain operations. One example of this is Compound Governance’s COMP distribution. Once an address has earned 0.001 COMP, any Compound transaction (e.g. supplying an asset, or transferring a cToken) will automatically transfer COMP to their wallet.

You can implement the above logic in a function modifier (a decorator), wrap the modifier around a function, and have the logic automatically executed whenever the function is called. The caller will pay the gas required for the additional logic.

However, not all smart contract systems follow this approach. One reason is that it can lead to unpredictable gas usage, since these modifiers may only run under certain conditions. It also forces additional gas fees onto a random subset of users, who just happened to be the unlucky few selected to ‘rebalance’ the contract.

Finally, somebody still needs to call the smart contract for the code to run.

Common Use Cases for Smart Contract Automation

DeFi protocols already rely on some kind of off-chain smart contract automation. MakerDAO relies on third party Keepers to monitor the collateralization ratios of debt positions and liquidate any undercollateralized position. Other DeFi protocols have similar needs.

There are two, often overlapping use cases around off-chain smart contract automation:

• Automated Triggers: You want to execute a contract under a certain condition.
• State and Event Monitoring: You want to know when a contract is in a certain condition.

#serverless #solidity #smart-contracts #javascript #decentralization