Skip to main content

​
Overview

​
What is the Schedule Service?

The Schedule Service is Hedera’s native solution for coordinating multi-signature transactions and delayed execution. It allows you to create a transaction that collects signatures from multiple parties on-chain before executing, eliminating the need for off-chain signature coordination. When you create a scheduled transaction, you’re essentially posting a transaction to the network that waits for all required signatures before executing. This makes it ideal for scenarios where multiple parties need to approve a transaction, or when you need to delay execution until a specific time.

​
Why Use Scheduled Transactions?

Scheduled transactions solve several common challenges in distributed systems:
  • Simplified Multi-Signature Coordination: Instead of collecting signatures off-chain and coordinating with multiple parties, you can post the transaction on-chain and let each party sign it independently.
  • Transparent Approval Process: All signatures are publicly visible on the network, providing full transparency into who has approved the transaction.
  • Automated Execution: Once all required signatures are collected, the transaction executes automatically—no additional coordination needed.
  • Time-Based Execution: You can schedule transactions to execute at a specific time in the future (up to 62 days), enabling automated workflows and delayed operations.

​
Common Use Cases

Multi-Signature Payments A treasury account requires approval from three executives before releasing funds. The CFO creates a scheduled transfer transaction, and the other two executives sign it through the network. Once all three signatures are collected, the payment executes automatically. Delayed Token Distributions A project schedules token airdrops to vest over time. By creating scheduled transactions with future expiry times and the wait_for_expiry flag enabled, tokens are automatically distributed at predetermined dates without manual intervention. Automated Recurring Payments A subscription service creates scheduled transactions for monthly payments. Each transaction is set to execute at a specific future date, automating the payment process and reducing operational overhead.

​
How Scheduled Transactions Work

Unlike other Hedera transactions, scheduled transactions allow you to queue a transaction for future execution (up to two months into the future). This feature is ideal for transactions that require multiple signatures and would benefit from being submitted on-chain. The transaction types that can be scheduled in a schedule transaction as of Consensus Node Release 0.57 are the following:
  • TransferTransaction
  • TokenMintTransaction
  • TokenBurnTransaction
  • AccountCreateTransaction
  • AccountUpdateTransaction
  • FileUpdateTransaction
  • SystemDeleteTransaction
  • SystemUndeleteTransaction
  • FreezeTransactions
  • ContractExecuteTransaction
  • ContractCreateTransaction
  • ContractUpdateTransaction
  • ContractDeleteTransaction
Transaction Throttles Schedule transactions are throttled based on the transaction they contain. For example, a scheduled transaction containing the transaction type of “CryptoTransfer” would be throttled as defined here. [Reference: HIP-423]

​
Creating a Schedule Transaction

When a schedule transaction is created, the following information will need to be specified in the ScheduleCreateTransaction.

​
Scheduled Transaction ID

The Transaction ID of the transaction that needs to be scheduled. You will need to create the transaction that you would like to schedule prior to creating the schedule transaction. Once you have created the transaction you want to schedule, you will need to specify that transaction ID in this field. Admin Key Setting an admin key on a schedule transaction allows the user to cancel or delete the schedule transaction, if needed. This key is optional to set. If this key is not set upon creation, the transaction cannot be deleted. Expiration Time The expiration time is a timestamp for specifying when the transaction should be evaluated for execution and then expire. The maximum allowed value is 62 days (5356800 seconds).
  • Scheduled Transactions will execute at the earliest available consensus time after their expiration time on a best-effort basis.
Wait for Expiry The default behavior for a scheduled transaction is to automatically execute when the required number signatures for the transaction are received . If the transaction should wait for the specified expiry time to send the transaction to the network, you can optionally enable the wait_for_expiry flag.
  • When set to true, the transaction will be evaluated for execution at expiration_time instead of when all required signatures are received.
  • When this flag is set to false, the transaction will execute immediately after sufficient signatures are received
Payer Account ID The account ID of the account responsible for paying the transaction fees of the scheduled transaction. This field is optional. If not set, the transaction fee payer for the schedule transaction defaults to the transaction fee payer account of the scheduled transaction. Schedule Memo Publicly visible text that is stored with the schedule transaction and can be viewed in a network explorer up to 100 bytes and does not include the zero byte.

Create A Schedule Transaction

​
Signing and Submitting a Schedule Transaction

Before submitting your scheduled transaction, you must sign it with the key of the account responsible for paying the schedule transaction fees and, optionally, the key of the transaction fee payer account for the scheduled transaction, if specified. Additionally, if your signature is required for the scheduled transaction, you can sign the ScheduleCreateTransaction using that key. After a ScheduleCreateTransaction successfully executes, the receipt will include the schedule ID and the scheduled transaction ID. The schedule ID is a unique identifier used to reference the created schedule transaction. The scheduled transaction ID represents the transaction scheduled by the schedule transaction. Scheduled transaction IDs include a ?scheduled flag at the end (e.g., 0.0.1234@1615422161.673238162?scheduled), indicating it is a scheduled transaction. This ID inherits the valid start time and the account ID from the original schedule transaction. You can request the current state of a schedule transaction by querying the network for ScheduleGetInfoQuery using the schedule ID. The request will return the following information:
  • Schedule ID
  • Account ID that created the schedule transaction
  • Account ID that paid for the creation of the scheduled transaction
  • Transaction body of the transaction that was scheduled
  • Transaction ID for the transaction that was scheduled
  • Current list of signatures
  • Admin key (if any)
  • Expiration time
  • The timestamp of when the transaction was deleted, if true

Get Schedule Info

​
Signing the Scheduled Transaction

After the schedule transaction is submitted, the scheduled transaction becomes available for on-chain signing. Required parties can use a ScheduleSignTransaction to add their signatures to the scheduled transaction. Once the minimum number of signatures is collected, the transaction will automatically execute, unless it is configured to wait until the expiry timestamp. Scheduled Transaction Record Once the schedule transaction successfully executes, the transaction record is made available. To get the transaction record for the scheduled transaction after successful execution, you can do the following:
  1. Poll the network for the specified scheduled transaction ID. Once the schedule transaction executes the scheduled transaction successfully, request the record for the scheduled transaction using the scheduled transaction ID.
  2. Query a Hedera mirror node for the scheduled transaction ID.
  3. Run your own mirror node and query for the scheduled transaction ID.

Sign A Schedule Transaction

​
Deleting a schedule transaction

A schedule transaction can be deleted if an admin key was set during its creation. If no admin key was set, the schedule transaction cannot be deleted.

Delete A Schedule Transaction

​
Tutorial/Examples

Schedule Your First Transaction

​
FAQ

A schedule transaction is a transaction that can schedule any Hedera transaction with the ability to collect the required signatures on the Hedera network in preparation for its execution.A scheduled transaction is a transaction that was scheduled by the schedule transaction.
Yes, the entity ID is referred to as the schedule ID which is returned in the receipt of the ScheduleCreateTransaction.
Refer to the Overview section of this page.
  • The creator of the schedule transaction can provide you a schedule ID which you specify in the ScheduleSignTransaction to submit your signature.
If the fee payer account for the scheduled transaction (e.g., a transfer transaction) does not have a sufficient balance, the scheduled transaction will fail. However, the schedule transaction itself will still be considered successful.
No, you cannot delay or modify a scheduled transaction once it’s been submitted to a network. You would need to delete the scheduled transaction and create a new one with the modifications. If the transaction cannot be deleted, the transaction will need to expire.
  • The first transaction to reach consensus will create the schedule transaction and provide the schedule entity ID
  • The other users will get the schedule ID in the receipt of the transaction that was submitted. The receipt status will result in IDENTICAL_SCHEDULE_ALREADY_CREATED. These users would need to submit a ScheduleSignTransaction to append their signatures to the schedule transaction.
The scheduled transaction executes when the last signature is received. Unless, the wait for expiry flag was enabled.
Every time the scheduled transaction is signed.
You can submit a schedule info query request to the network.
A scheduled transaction expires at the specified expiration date/time.
The transaction receipt for a schedule that was created contains the new schedule entity ID and the scheduled transaction ID.