Hedera Schedule Service

​

Overview

• DeFi Automation: Automatically rebalancing a portfolio or harvesting yield farming rewards.
• Vesting Schedules: Creating token vesting contracts that automatically release tokens at specified intervals.
• DAO Operations: Scheduling recurring governance tasks, such as distributing rewards or executing proposals.

​

authorizeSchedule(address)

• Signs the schedule transaction identified by the pass-in parameter (address) with a ContractKey using the format 0.0.<ContractId of the calling contract>.
• Allows contracts to sign schedule transactions using their own contract key.
• Returns a responseCode indicating the success or failure of the authorization attempt.

​

signSchedule(address schedule, bytes memory signatureMap)

• Allows for the signing of a schedule transaction given a protobuf encoded signature map.
• The message signed by the keys is defined to be the concatenation of the shard, realm, and schedule transaction address.
• Returns a responseCode indicating the success or failure of the signature addition attempt.

​

scheduleNative(address systemContractAddress, bytes memory callData, address payer)

• Allows for the creation of a schedule transaction for a given system contract address, ABI-encoded call data, and payer address.
• Currently supports the Hedera Token Service System Contract (0x167) for token-related functions.
• Returns the scheduleAddress of the newly created scheduled transaction and a responseCode.

​

getScheduledCreateFungibleTokenInfo(address scheduleAddress)

• Returns the token information for a scheduled fungible token create transaction.
• scheduleAddress: The address of the scheduled fungible token create transaction.
• Returns a responseCode and an IHederaTokenService.FungibleTokenInfo struct.

​

getScheduledCreateNonFungibleTokenInfo(address scheduleAddress)

• Returns the token information for a scheduled non-fungible token create transaction.
• scheduleAddress: The address of the scheduled non-fungible token create transaction.
• Returns a responseCode and an IHederaTokenService.NonFungibleTokenInfo struct.

​

scheduleCall(address to, uint256 expirySecond, uint256 gasLimit, uint64 value, bytes memory callData)

• Schedules a contract call with the calling contract acting as the payer.
• to: The address of the contract to call.
• expirySecond: The epoch second at which the transaction should expire.
• gasLimit: The maximum amount of gas to use for the call.
• value: The amount of HBAR (in tinybars) to send with the call.
• callData: The ABI-encoded data for the function call.
• Returns a responseCode indicating success or failure (22 for SUCCESS) and the scheduleAddress of the newly created scheduled transaction.

​

scheduleCallWithPayer(address to, address payer, uint256 expirySecond, uint256 gasLimit, uint64 value, bytes memory callData)

• Schedules a contract call with a specified payer address. This method collects the required signatures but only executes the transaction at the expirySecond timestamp, even if all signatures are gathered earlier. The payer must provide signatures before the transaction can execute.
• to: The address of the contract to call.
• payer: The address of the account that will pay for the transaction.
• expirySecond: The epoch second at which the transaction should expire.
• gasLimit: The maximum amount of gas to use for the call.
• value: The amount of HBAR (in tinybars) to send with the call.
• callData: The ABI-encoded data for the function call.
• Returns a responseCode indicating success or failure (22 for SUCCESS) and the scheduleAddress of the newly created scheduled transaction.

​

executeCallOnPayerSignature(address to, address payer, uint256 expirySecond, uint256 gasLimit, uint64 value, bytes memory callData)

• Schedules and executes a contract call immediately upon receiving the payer’s signature. This method also collects signatures, but executes the transaction immediately once all required signatures are present, without waiting for the expirySecond timestamp, unless the consensus time has already passed the expirySecond.
• to: The address of the contract to call.
• payer: The address of the account that will pay for the transaction.
• expirySecond: The epoch second at which the transaction should expire.
• gasLimit: The maximum amount of gas to use for the call.
• value: The amount of HBAR (in tinybars) to send with the call.
• callData: The ABI-encoded data for the function call.
• Returns a responseCode indicating success or failure (22 for SUCCESS) and the scheduleAddress of the newly created scheduled transaction.

​

deleteSchedule(address scheduleAddress)

• Deletes a previously scheduled transaction.
• scheduleAddress: The address of the scheduled transaction to delete.
• Returns a responseCode indicating success or failure (22 for SUCCESS).

​

deleteSchedule()

• Deletes a scheduled transaction by calling this parameter-less redirect function directly on the schedule’s address.
• This provides a convenient alternative for contracts or Externally Owned Accounts (EOAs) to the main deleteSchedule(address) function.
• Returns a responseCode indicating success or failure (22 for SUCCESS).

​

hasScheduleCapacity(uint256 expirySecond, uint256 gasLimit)

• A view function that checks if there is enough capacity on the network to schedule a contract call at a given time with a specified gas limit.
• expirySecond: The epoch second to check for capacity.
• gasLimit: The gas limit of the call to check for capacity.
• Returns true if there is capacity, false otherwise.
• For a reliable retry pattern, consider implementing a method similar to findAvailableSecond() as described in HIP-1215.

​

Behavior and Costs

​

Behavior

• Scheduled transactions must collect all required signatures before they can be executed. These signatures can be added asynchronously using the signSchedule function.
• If all required signatures are not received within the specified expiration window, the transaction expires and is removed from the network.
• The execution of a schedule transaction occurs automatically when the final required signature is submitted.
• Throttling and Capacity: The main design concern for scheduled contract calls is managing network capacity. The hasScheduleCapacity() view function allows contracts to check if a given second has capacity to schedule a contract call with a specified gas limit. This enables contracts to find an acceptable second for execution with an affordable gas budget.
• Return Values: The new scheduleCall functions do not revert. On success, they return the address of the newly created scheduled transaction and a SUCCESS (22) response code. On failure, they return a zero address and a failure response code from the ResponseCodeEnum.

​

Costs

• Schedule transaction fees are the same as a HAPI sign schedule transaction, with a 20% markup for using system contracts.
• Fees include gas costs for EVM execution, storage costs, and network fees for consensus.
• Expired transactions cost no additional fees beyond the initial scheduling and signature costs.

​

Reference

• HIP-1215: Generalized Scheduled Contract Calls
• HIP-756: Contract Scheduled Token Create
• HIP-755: Schedule Service System Contract