Most blockchains cannot run a smart contract on a schedule. On the Internet Computer from @dfinity, the protocol gives each smart contract, called a canister, its own timer, so the network ru
Most blockchains cannot run a smart contract on a schedule. On the Internet Computer from @dfinity, the protocol gives each smart contract, called a canister, its own timer, so the network runs the task when the time comes.
On most blockchains, a smart contract sits idle until an outside transaction wakes it up. According to Chainlink, smart contracts cannot trigger their own functions and need an external entity to call them through an on-chain transaction. Many rely on an external entity known as a keeper to monitor predefined conditions and trigger the contract when they are met.
In practice, projects often pay outside bots to send that nudge on time. Developers have also tried running their own centralized scripts. A Chainlink tutorial notes that this approach undermines the purpose of a decentralized application and creates the risk of downtime if the script fails.
Internet Computer documentation says canisters can schedule work to run automatically, after a delay or on a repeating interval, without any external trigger. The capability is built into the protocol rather than added through an offchain scheduler.
At the protocol level, each canister has a single global timer, a timestamp stored alongside its state. When the execution environment reaches that time, it delivers a message to the canister, which handles it like any other update call. Developer libraries for Rust, Motoko and TypeScript (Azle) build on this to support multiple and periodic timers, so a canister can run a task once or repeat it at a set interval.
The original design also ties into the network's fuel model. An idle timer costs nothing in cycles, the unit that $ICP converts into. Tasks triggered by the library still incur normal costs: the documentation notes that each expired task starts a self-canister call, and standard inter-canister call costs apply.
Timing is a minimum, not an exact schedule. Internet Computer documentation describes timers as calls with a specified minimum timeout or interval, and tasks can run late when the network is busy.
Timers also do not survive code upgrades on their own. The documentation states that the timers library does not handle canister upgrades, and it is up to the developer to serialize and reactivate timers if needed. In practical terms, developers must set timers again after an upgrade. The same documentation also discourages the use of pre- and post-upgrade hooks, calling them error-prone, so teams need to plan this step carefully.
For builders weighing platforms, the feature removes one common dependency on outside infrastructure for time-based logic, such as recurring payouts or periodic clean-up jobs. It does not guarantee exact execution times, which matters for applications that need tight timing.
Sources
