Please describe the feature you'd like to see added.
Overview
In certain cases the user creating a transaction would like to broadcast it to the bitcoin network delayed, not immediately. It's practical to implement scheduling in the node, as it is a software component designed to be always-on.
With Scheduled Transaction Broadcast the bitcoin node accepts a transaction for later broadcast, stores it, and broadcasts automatically at the specified target time.
Is your feature related to a problem, if so please describe it.
No response
Describe the solution you'd like
Details / Caveats
Uses. Delayed transaction broadcast can be useful for/when (among others):
- hiding the real time of transaction creation (with random delay; for non-urgent transactions; typically in the range of few hours -- few days)
- broadcasting a transaction at a future date
Result, error check. As the actual broadcast happens later, the broadcast result -- success or some error -- is not available at acceptance time. Only parsing checks are done at acceptance time. The client can check the result only by monitoring the bitcoin network. Note: some checks are not possible to be done at acceptance time, as conditions may change (e.g. inputs with timelocks). (Note: it could be possible to offer an API to query for broadcast result, but that's not planned.)
Absolute time vs. block time. The target time can be specified as an absolute time or a block height.
No guarantees. Delayed broadcast is best-effort, there is no delivery guarantee.
Fee. The transaction fee is contained in the scheduled transaction, and it is not possible to be changed. In case the network fee rate goes up by the time of submission, the fee may be insufficient. CFCP can be used to bump the fee if needed.
Retries. It is possible to specify a number of retries, and a retry period. Then the scehduled broadcast is retried accordingly in case of failure.
Describe any alternatives you've considered
The following alternatives are identified, though they are outside of the scope of the node software:
- Scheduling implemented in the wallet software. The drawback is that wallets are typically active (running) only for a short period, while there is user interaction. Running in the background may impose some design issues.
- Implemented in a separate component sitting along the bitcoin node, proxying all RPC API calls, and implementing scheduled (delayed) transaction broadcast.
Miscellaneous
Note (added Jan 15): earlier feature request #30471 also includes delayed broadcast.
This could interfere with the feature "Broadcast own transactions only via short-lived Tor or I2P connections" (PR ##29415).
This feature could be combined with this feature, to further mask the real transaction creation time, by creating the dedicated sending connection sometimes between the scheduling time and target time (randomized).
An APIs for cancelling an unsent scheduled TX would be possible to offer as well.
Please leave any additional context
Implementation Details
Scheduled transactions are kept in a separate memory structure, and are persisted to a separate file (for persistence accross restarts). The file is read at startup, and written whenever there is a relevant change to its content, and at shutdown.
A new RPC 'schedulerawtransaction' is proposed, with syntax very similar to 'sendrawtransaction'. However, the transaction is not sent rigth away, but stored for later broadcast.
Status
Delving discussion:
https://delvingbitcoin.org/t/scheduled-delayed-transaction-broadcast/2148
Prototype:
https://github.com/optout21/sched-tx-ptoto/
https://github.com/optout21/bitcoin/tree/sched-tx-proto1
https://github.com/optout21/bitcoin/tree/sched-tx-proto0
History
Jan 14: Added ref to #30471, @craigraw .
Jan 5, 2026: Edits w.r.t. to the alternative of implementing in the client; removing speculative fuzzy use case; in response to comments by @ismaelsadeeq .
Dec 19, 2025: Created.
Please describe the feature you'd like to see added.
Overview
In certain cases the user creating a transaction would like to broadcast it to the bitcoin network delayed, not immediately. It's practical to implement scheduling in the node, as it is a software component designed to be always-on.
With Scheduled Transaction Broadcast the bitcoin node accepts a transaction for later broadcast, stores it, and broadcasts automatically at the specified target time.
Is your feature related to a problem, if so please describe it.
No response
Describe the solution you'd like
Details / Caveats
Uses. Delayed transaction broadcast can be useful for/when (among others):
Result, error check. As the actual broadcast happens later, the broadcast result -- success or some error -- is not available at acceptance time. Only parsing checks are done at acceptance time. The client can check the result only by monitoring the bitcoin network. Note: some checks are not possible to be done at acceptance time, as conditions may change (e.g. inputs with timelocks). (Note: it could be possible to offer an API to query for broadcast result, but that's not planned.)
Absolute time vs. block time. The target time can be specified as an absolute time or a block height.
No guarantees. Delayed broadcast is best-effort, there is no delivery guarantee.
Fee. The transaction fee is contained in the scheduled transaction, and it is not possible to be changed. In case the network fee rate goes up by the time of submission, the fee may be insufficient. CFCP can be used to bump the fee if needed.
Retries. It is possible to specify a number of retries, and a retry period. Then the scehduled broadcast is retried accordingly in case of failure.
Describe any alternatives you've considered
The following alternatives are identified, though they are outside of the scope of the node software:
Miscellaneous
Note (added Jan 15): earlier feature request #30471 also includes delayed broadcast.
This could interfere with the feature "Broadcast own transactions only via short-lived Tor or I2P connections" (PR ##29415).
This feature could be combined with this feature, to further mask the real transaction creation time, by creating the dedicated sending connection sometimes between the scheduling time and target time (randomized).
An APIs for cancelling an unsent scheduled TX would be possible to offer as well.
Please leave any additional context
Implementation Details
Scheduled transactions are kept in a separate memory structure, and are persisted to a separate file (for persistence accross restarts). The file is read at startup, and written whenever there is a relevant change to its content, and at shutdown.
A new RPC 'schedulerawtransaction' is proposed, with syntax very similar to 'sendrawtransaction'. However, the transaction is not sent rigth away, but stored for later broadcast.
Status
Delving discussion:
https://delvingbitcoin.org/t/scheduled-delayed-transaction-broadcast/2148
Prototype:
https://github.com/optout21/sched-tx-ptoto/
https://github.com/optout21/bitcoin/tree/sched-tx-proto1
https://github.com/optout21/bitcoin/tree/sched-tx-proto0
History
Jan 14: Added ref to #30471, @craigraw .
Jan 5, 2026: Edits w.r.t. to the alternative of implementing in the client; removing speculative fuzzy use case; in response to comments by @ismaelsadeeq .
Dec 19, 2025: Created.