> ## Documentation Index
> Fetch the complete documentation index at: https://hedera-0c6e0218-mintlify-enhance-scheduled-transaction-over.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Schedule Transaction

## 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

<Frame>
  ```mermaid theme={null}
  graph TD
      A[Create Schedule Transaction] --> B[Post to Network]
      B --> C{Collect Signatures}
      C --> D[Party 1 Signs]
      C --> E[Party 2 Signs]
      C --> F[Party N Signs]
      D --> G{All Signatures Collected?}
      E --> G
      F --> G
      G -->|Yes| H{Wait for Expiry?}
      G -->|No| I{Expiry Time Reached?}
      H -->|No| J[Execute Immediately]
      H -->|Yes| K[Wait Until Expiry]
      I -->|Yes| L[Transaction Expires]
      I -->|No| C
      K --> J
      J --> M[Transaction Complete]
      
      style A fill:#e1f5ff
      style J fill:#d4edda
      style L fill:#f8d7da
      style M fill:#d4edda
  ```
</Frame>

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](/hedera/networks/mainnet).

\[[Reference: HIP-423](https://hips.hedera.com/hip/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](https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/hedera-config/src/main/java/com/hedera/node/config/data/SchedulingConfig.java#L35)).

* 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.

<Card title="Create A Schedule Transaction" href="/hedera/sdks-and-apis/sdks/schedule-transaction/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

<Card title="Get Schedule Info" href="/hedera/sdks-and-apis/sdks/schedule-transaction/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.

<Card title="Sign A Schedule Transaction" href="/hedera/sdks-and-apis/sdks/schedule-transaction/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.

<Card title="Delete A Schedule Transaction" href="/hedera/sdks-and-apis/sdks/schedule-transaction/delete-a-schedule-transaction" />

***

## Tutorial/Examples

<Card title="Schedule Your First Transaction" href="/hedera/tutorials/more-tutorials/schedule-your-first-transaction" />

***

## FAQ

<Accordion title="What is the difference between a schedule transaction and scheduled transaction?">
  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.
</Accordion>

<Accordion title="Is there an entity ID assigned to a schedule transaction?">
  Yes, the entity ID is referred to as the **schedule ID** which is returned in the receipt of the `ScheduleCreateTransaction`.
</Accordion>

<Accordion title="What transactions can be scheduled?">
  Refer to the Overview section of this page.
</Accordion>

<Accordion title="How can I find a scheduled transaction that requires my signature?">
  * The creator of the schedule transaction can provide you a schedule ID which you specify in the `ScheduleSignTransaction` to submit your signature.
</Accordion>

<Accordion title="What happens if the scheduled transaction does not have sufficient balance?">
  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.
</Accordion>

<Accordion title="Can you delay a transaction once it has been scheduled?">
  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.
</Accordion>

<Accordion title="What happens if multiple users create the same schedule transaction?">
  * 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.
</Accordion>

<Accordion title="When does the scheduled transaction execute?">
  The scheduled transaction executes when the last signature is received. Unless, the wait for expiry flag was enabled.
</Accordion>

<Accordion title="How often does the network check to see if the scheduled transaction has met the signature requirement?">
  Every time the scheduled transaction is signed.
</Accordion>

<Accordion title="How do you get information about a schedule transaction?">
  You can submit a [schedule info query](/hedera/sdks-and-apis/sdks/schedule-transaction/get-schedule-info) request to the network.
</Accordion>

<Accordion title="When does a schedule transaction expire?">
  A scheduled transaction expires at the specified expiration date/time.
</Accordion>

<Accordion title="What does a schedule transaction receipt contain?">
  The transaction receipt for a schedule that was created contains the new schedule entity ID and the scheduled transaction ID.
</Accordion>