Monad Draft Proposes Protocol-Level Scheduling for Future Contract Calls
The design would store scheduled transactions until their target block and reserve up to 10% of a block’s gas target for them.

A draft proposal from Andrei Constantinescu and Lioba Heimbach would let Monad accounts and smart contracts schedule transactions for future blocks, shifting recurring on-chain tasks from external keepers to protocol execution. The authors posted the Draft v1 design on Monad’s research forum Oct. 22.
Smart contracts need a transaction to call them; they do not initiate actions independently. Applications that need a future or recurring operation often rely on keeper software, run by an app team or a third party, to submit the triggering transaction. That automation can stop if the software has a bug, its service goes down or its gas wallet runs out of funds.
Under the draft, an account or contract would use a protocol-provided precompile to book a transaction for a selected block. An accepted schedule would remain in the state tree until that block, then be added to the end of the block in the order it was accepted. The protocol would handle the scheduled execution rather than requiring an outside keeper to submit the call at that time.
The design would reserve up to 10% of a block’s gas target for scheduled transactions, leaving 90% for regular transactions. Scheduled capacity would open gradually as the target block approaches. Gas and storage fees would be paid when a transaction is scheduled, while any value it is set to transfer would remain in escrow until execution.
The account or contract that creates a schedule would own it and could cancel it while the cancellation window is open. An accepted call that has not been canceled is scheduled to run at its target block, but execution does not ensure success: the draft’s status model counts a transaction as completed once it fires, even if it reverts.
Potential uses include recurring payments, staking reward distributions, long-running computations, refunds for swaps that do not complete and clearing expired orders. The core design schedules by block height; scheduling by clock time, across a range of blocks or with spare capacity are listed as possible extensions.
The proposal remains Draft v1, and its specification has not been finalized. It gives no implementation or launch date.