Scheduled Transactions is a new capability available on Hedera that enables multiple parties to easily, inexpensively, and natively schedule and execute any type of Hedera transaction together.
Coordination among members in an organization can be cumbersome and often require an off-ledger mechanism to communicate and send their signatures. In this scenario, members would need to elect a single authority to collect these signatures and submit a single transaction to the network, creating a single point of failure. This contributes to a lack of transparency and traceability for the actions taken by each party. The Scheduled Transaction capability completely eliminates these complexities through a simple API interface.
Using Scheduled Transactions, developers can build new types of applications never before possible on Hedera, such as decentralized exchanges, validator networks, decentralized network bridges, oracles, and more. Without it, application developers would need to write this logic in a slow and expensive smart contract or a layer 2 network. Scheduled Transactions enable a fast, secure, and economically feasible alternative.
This blog post details the challenges of multi-signature transactions today, how Scheduled Transactions overcomes those challenges, the architecture of Scheduled Transactions, application use cases, detailed functionalities, and what the future holds.
You can start developing with the Scheduled Transactions capability today using v2 of the officially supported SDKs (Javascript, Go, and Java). Only the CryptoTransfer and ConsensusSubmitMessage transactions are available for use with the Scheduled Transactions capability today but all Hedera transactions will eventually be able to be scheduled. A step-by-step getting started with Scheduled Transactions tutorial is available. Watch Leemon Baird, Hedera Co-Founder and Chief Scientist, Explain the Scheduled Transactions capability and the problems it solves for decentralized applications.
Hedera entities such as accounts and topics require signature(s) either from a single key or a minimum number of keys (i.e. multisig) from the predefined set. Multisig keys offer a high degree of security because multiple independent key-holders need to collaborate and come to an agreement before submitting a transaction to the Hedera network.
While entities controlled by multisig keys are more secure, they often require more work. To submit a transaction, one of the parties must first create a transaction and send it to other parties so that they can sign on that transaction. This process is typically done off-ledger using other communication means such as email or sharing using shared folders.
This off-ledger communication creates the inconvenience of having to worry about the availability and security of the off-ledger infrastructure. In addition, one of the parties needs to collect all these signatures and collate them together so that they can submit a single multisig signed transaction to the network for execution. That creates a single point of failure in the system. Further, this process is oftentimes opaque because unless the transaction is submitted to the network, there is no record of which parties signed on the transaction and which parties didn’t.
To address this problem, Hedera has developed a capability called Scheduled Transactions. A scheduled transaction is any type of transaction on Hedera that can schedule any Hedera transaction type with the ability to collect the required signatures on the Hedera network in preparation for its execution. Here is how it works:
One of the parties that are required to sign the multisig transaction, Alice, creates the actual transaction that needs to be executed on the network and specifies the list of signers for the transaction. This transaction can be any normal Hedera transaction such as cryptoTransfer or HCS submitMessage. This transaction is called the ‘inner transaction’.
The creating party then adds their signature to this transaction, and submits this to the network using another encapsulating transaction called the ‘outer transaction’. The inner transaction often does not have the minimum number of signatures required for a successful execution at this time.
Hedera network executes the outer transaction immediately and creates a new entity in the state that remembers this inner transaction for execution at a future time.
Other signatories that were listed as required signers defined in step 1, say Bob, Carol, and Dave, can query the mainnet or the mirror nodes for this scheduled transaction. If they agree to sign the transaction, they add their respective signatures using a signSchedule primitive.
Once the minimum required number of parties sign this inner scheduled transaction, Hedera executes the inner transaction as if it was submitted with the collated set of signatures at the time when the last signature was added.
Transaction records are generated for the inner as well as outer transactions separately for full traceability.
Scheduled Transactions can be used for a variety of use cases that involve multi-signature transactions, which need coordination between multiple parties over a period of time.
Decentralized ValidatorsDecentralized validators commonly require multiple validators to witness events in the real-world — such as the value of a stock, the result of a sporting event, or weather information — and consequently trigger a multi-signature transaction on Hedera.
This pattern is common in decentralized oracles, which provide a trustable and reliable source of real-world events that can be acted upon by the listeners. Using Scheduled Transactions, multiple network validators can sign once a specific data point is met and consequently execute a transaction together.
For example, various score keepers of a playoff sporting event may sign a scheduled transaction to execute the issuance of a championship NFT to the team’s account.
Interoperable Network BridgesSimilarly, validators that provide interoperability bridging service between disparate blockchains also need to coordinate on signing a multisig transaction.
Multisignature Cryptocurrency Transactions in Third-Party WalletsThird-party wallets that support multisig transactions can use this capability to make the multisig signing process easy and transparent.
Purchase or Sale of an Asset by Multiple PartiesAnother example is a business transaction, where all partners in a firm must agree to the sale or purchase of an asset — they can use Hedera’s multisig functionality to each sign the scheduled transaction for it to execute.
Council Transaction ToolHedera council members sign multisig transactions that affect the governance and control of Hedera, and the council members use a tool to coordinate that effort. Once the ‘Execute At’ functionality, described in the section below, is implemented, Scheduled Transactions can be used for that use case as well.
Hedera AuctionA live example of Scheduled Transactions will be on showcase in the upcoming Hedera NFT Auction. The open-source demo uses a Scheduled Transaction to manage bid refunds and distribute the NFT to the auction’s winner from a multi-signature account.
Coordination among various signatories of a multisig transaction is oftentimes a cumbersome process. The parties need to find an off-ledger mechanism to communicate with each other and send their signatures. They also have to agree upon a time by which these signatures are collected and make a pre-determination of the transaction execution time. Once a sufficient number of parties provide their signatures, one or more of these parties need to collate all signatures and submit the transaction to the Hedera network for execution. Scheduled Transactions completely eliminates these complex steps for the users and provides a simple API interface to the users.
Parties in the multisig signatories often elect one of them to collect and collate all signatures and to submit a single transaction to the network. Real-world deployment of this architecture needs to worry about the reliability of that particular computer as well as the possibility that that particular computer could be malicious.
With Scheduled Transactions, the transaction that is awaiting signatures from other signatories is stored on the decentralized nodes of the Hedera mainnet. And it is not affected by the availability, reliability, or integrity of any one of the computers used by the signatories. This provides significantly enhanced reliability in terms of ensuring that the transaction will get executed if a sufficient number of signatures are gathered.
Every single transaction, such as the creation of the scheduled transaction as well as individual parties adding their respective signatures to that transaction, are also Hedera transactions. This provides complete transparency and traceability of all actions by each of the parties involved relative to the given transaction. Applications can query the records of these events and use them for various purposes ranging from auditability to incentivizing the nodes that provide signatures and punishing those that don’t.
A user creates a scheduled transaction using scheduleCreate API. This creates an entity called ScheduleID on Hedera that is used for collecting the signatures from other signatories. The user can optionally specify an administrative key that has the authority to delete the schedule and a memo, similar to other Hedera entities. In the current implementation, the scheduled transaction executes as soon as the minimum threshold of signatures is reached, and therefore the user does not specify the time at which the transaction should be executed. Please see the section on future enhancements below on how this capability will evolve to specify the execution at a prespecified time.
Other parties can add a signature to this transaction using ScheduleSign API. This call references the scheduled entity to which these signatures are attached.
Every time a signature is added to the scheduled entity, a record is generated for that transaction. When the last required signature is added and the threshold for the minimum number of signatures is met, the network executes the inner transaction that was scheduled, and transaction records are generated both for the last signTransaction transaction that triggered the execution of the inner transaction and for the inner transaction. These records can be queried by the mirror nodes.
If the scheduled transaction fails to obtain the minimum number of valid signatures, it expires after the preconfigured expiry period and is deleted from the memory. Currently, that period is configured to be 30 minutes.
Scheduled Transactions simplifies the task of coordination between multiple signatories in a multisig transaction and makes that process transparent and auditable. Here are a few directions in which this capability could evolve:
In the current implementation, the inner scheduled transaction executes as soon as the minimum number of signatures are collected. There are some really interesting use-cases where the users want the transaction to be executed at a given time in the future. In the future, this API may optionally allow the user to specify the time at which this transaction should be executed, assuming there were enough signatures for successful execution.
Currently, a scheduled transaction exists on the network only for 30 minutes. This means that all the parties must add their signatures in that 30 minutes window. If the scheduled transaction fails to meet the bar of a minimum number of signatures as specified at the time of scheduled creation, that scheduled transaction expires and is deleted from the memory. In the future, Hedera may extend this time to a longer duration.
With the open sourcing of Hedera services software in August 2020, we had committed to decentralizing the development of the services layer as well. Development of Scheduled Transactions is an important milestone along that journey since this marks the second major capability developed by one of our ecosystem partners, Limechain.