/**
 * # Schedule Create
 * Message to create a schedule, which is an instruction to execute some other
 * transaction (the scheduled transaction) at a future time, either when
 * enough signatures are gathered (short term) or when the schedule expires
 * (long term). In all cases the scheduled transaction is not executed if
 * signature requirements are not met before the schedule expires.
 *
 * ### Keywords
 * The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 * "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 * document are to be interpreted as described in
 * [RFC2119](https://www.ietf.org/rfc/rfc2119) and clarified in
 * [RFC8174](https://www.ietf.org/rfc/rfc8174).
 */
syntax = "proto3";

package proto;

// SPDX-License-Identifier: Apache-2.0
option java_package = "com.hederahashgraph.api.proto.java";
// <<<pbj.java_package = "com.hedera.hapi.node.scheduled">>> This comment is special code for setting PBJ Compiler java package
option java_multiple_files = true;

import "services_basic_types.proto";
import "services_timestamp.proto";
import "services_schedulable_transaction_body.proto";

/**
 * Create a new Schedule.
 *
 * #### Requirements
 * This transaction SHALL create a new _schedule_ entity in network state.<br/>
 * The schedule created SHALL contain the `scheduledTransactionBody` to be
 * executed.<br/>
 * If successful the receipt SHALL contain a `scheduleID` with the full
 * identifier of the schedule created.<br/>
 * When a schedule _executes_ successfully, the receipt SHALL include a
 * `scheduledTransactionID` with the `TransactionID` of the transaction that
 * executed.<br/>
 * When a scheduled transaction is executed the network SHALL charge the
 * regular _service_ fee for the transaction to the `payerAccountID` for
 * that schedule, but SHALL NOT charge node or network fees.<br/>
 * If the `payerAccountID` field is not set, the effective `payerAccountID`
 * SHALL be the `payer` for this create transaction.<br/>
 * If an `adminKey` is not specified, or is an empty `KeyList`, the schedule
 * created SHALL be immutable.<br/>
 * An immutable schedule MAY be signed, and MAY execute, but SHALL NOT be
 * deleted.<br/>
 * If two schedules have the same values for all fields except `payerAccountID`
 * then those two schedules SHALL be deemed "identical".<br/>
 * If a `scheduleCreate` requests a new schedule that is identical to an
 * existing schedule, the transaction SHALL fail and SHALL return a status
 * code of `IDENTICAL_SCHEDULE_ALREADY_CREATED` in the receipt.<br/>
 * The receipt for a duplicate schedule SHALL include the `ScheduleID` of the
 * existing schedule and the `TransactionID` of the earlier `scheduleCreate`
 * so that the earlier schedule may be queried and/or referred to in a
 * subsequent `scheduleSign`.
 *
 * #### Signature Requirements
 * A `scheduleSign` transaction SHALL be used to add additional signatures
 * to an existing schedule.<br/>
 * Each signature SHALL "activate" the corresponding cryptographic("primitive")
 * key for that schedule.<br/>
 * Signature requirements SHALL be met when the set of active keys includes
 * all keys required by the scheduled transaction.<br/>
 * A scheduled transaction for a "long term" schedule SHALL NOT execute if
 * the signature requirements for that transaction are not met when the
 * network consensus time reaches the schedule `expiration_time`.<br/>
 * A "short term" schedule SHALL execute immediately once signature
 * requirements are met. This MAY be immediately when created.
 *
 * #### Long Term Schedules
 * A "short term" schedule SHALL have the flag `wait_for_expiry` _unset_.<br/>
 * A "long term" schedule SHALL have the flag  `wait_for_expiry` _set_.<br/>
 * A "long term" schedule SHALL NOT be accepted if the network configuration
 * `scheduling.longTermEnabled` is not enabled.<br/>
 * A "long term" schedule SHALL execute when the current consensus time
 * matches or exceeds the `expiration_time` for that schedule, if the
 * signature requirements for the scheduled transaction
 * are met at that instant.<br/>
 * A "long term" schedule SHALL NOT execute before the current consensus time
 * matches or exceeds the `expiration_time` for that schedule.<br/>
 * A "long term" schedule SHALL expire, and be removed from state, after the
 * network consensus time exceeds the schedule `expiration_time`.<br/>
 * A short term schedule SHALL expire, and be removed from state,
 * after the network consensus time exceeds the current network
 * configuration for `ledger.scheduleTxExpiryTimeSecs`.
 *
 * > Note
 * >> Long term schedules are not (as of release 0.56.0) enabled. Any schedule
 * >> created currently MUST NOT set the `wait_for_expiry` flag.<br/>
 * >> When long term schedules are not enabled, schedules SHALL NOT be
 * >> executed at expiration, and MUST meet signature requirements strictly
 * >> before expiration to be executed.
 *
 * ### Block Stream Effects
 * If the scheduled transaction is executed immediately, the transaction
 * record SHALL include a `scheduleRef` with the schedule identifier of the
 * schedule created.
 */
message ScheduleCreateTransactionBody {
    /**
     * A scheduled transaction.
     * <p>
     * This value is REQUIRED.<br/>
     * This transaction body MUST be one of the types enabled in the
     * network configuration value `scheduling.whitelist`.
     */
    SchedulableTransactionBody scheduledTransactionBody = 1;

    /**
     * A short description of the schedule.
     * <p>
     * This value, if set, MUST NOT exceed `transaction.maxMemoUtf8Bytes`
     * (default 100) bytes when encoded as UTF-8.
     */
    string memo = 2;

    /**
     * A `Key` required to delete this schedule.
     * <p>
     * If this is not set, or is an empty `KeyList`, this schedule SHALL be
     * immutable and SHALL NOT be deleted.
     */
    Key adminKey = 3;

    /**
     * An account identifier of a `payer` for the scheduled transaction.
     * <p>
     * This value MAY be unset. If unset, the `payer` for this `scheduleCreate`
     * transaction SHALL be the `payer` for the scheduled transaction.<br/>
     * If this is set, the identified account SHALL be charged the fees
     * required for the scheduled transaction when it is executed.<br/>
     * If the actual `payer` for the _scheduled_ transaction lacks
     * sufficient HBAR balance to pay service fees for the scheduled
     * transaction _when it executes_, the scheduled transaction
     * SHALL fail with `INSUFFICIENT_PAYER_BALANCE`.<br/>
     */
    AccountID payerAccountID = 4;

    /**
     * An expiration time.
     * <p>
     * If not set, the expiration SHALL default to the current consensus time
     * advanced by either the network configuration value
     * `scheduling.maxExpirationFutureSeconds`, if `wait_for_expiry` is set and
     * "long term" schedules are enabled, or the network configuration value
     * `ledger.scheduleTxExpiryTimeSecs` otherwise.
     */
    Timestamp expiration_time = 5;

    /**
     * A flag to delay execution until expiration.
     * <p>
     * If this flag is set the scheduled transaction SHALL NOT be evaluated for
     * execution before the network consensus time matches or exceeds the
     * `expiration_time`.<br/>
     * If this flag is not set, the scheduled transaction SHALL be executed
     * immediately when all required signatures are received, whether in this
     * `scheduleCreate` transaction or a later `scheduleSign` transaction.<br/>
     * This value SHALL NOT be used and MUST NOT be set when the network
     * configuration value `scheduling.longTermEnabled` is not enabled.
     */
    bool wait_for_expiry = 13;
}