All Downloads are FREE. Search and download functionalities are using the official Maven repository.

shgraph.hedera-protobuf-java-api.0.55.0.source-code.schedule_create.proto Maven / Gradle / Ivy

The newest version!
syntax = "proto3";

package proto;

/*-
 * ‌
 * Hedera Network Services Protobuf
 * ​
 * Copyright (C) 2018 - 2021 Hedera Hashgraph, LLC
 * ​
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 * ‍
 */

option java_package = "com.hederahashgraph.api.proto.java";
// <<>> This comment is special code for setting PBJ Compiler java package
option java_multiple_files = true;

import "basic_types.proto";
import "timestamp.proto";
import "schedulable_transaction_body.proto";

/**
 * Create a new schedule entity (or simply, schedule) in the network's action queue.
 * Upon SUCCESS, the receipt contains the `ScheduleID` of the created schedule. A schedule
 * entity includes a scheduledTransactionBody to be executed.
 * When the schedule has collected enough signing Ed25519 keys to satisfy the schedule's signing
 * requirements, the schedule can be executed.
 *
 * If Long Term Scheduled Transactions are enabled and wait_for_expiry is set to true, then the schedule
 * will execute at it's expiration_time.
 *
 * Otherwise it will execute immediately after the transaction that provided enough Ed25519 keys, a ScheduleCreate
 * or ScheduleSign.
 *
 * Upon `SUCCESS`, the receipt also includes the scheduledTransactionID to
 * use to query for the record of the scheduled transaction's execution (if it occurs). 
 * 
 * The expiration time of a schedule is controlled by it's expiration_time. It remains in state and can be queried
 * using GetScheduleInfo until expiration, no matter if the scheduled transaction has
 * executed or marked deleted. If Long Term Scheduled Transactions are disabled, the expiration_time is always
 * 30 minutes in the future.
 * 
 * If the adminKey field is omitted, the resulting schedule is immutable. If the
 * adminKey is set, the ScheduleDelete transaction can be used to mark it as
 * deleted. The creator may also specify an optional memo whose UTF-8 encoding is at most
 * 100 bytes and does not include the zero byte is also supported.
 * 
 * When a scheduledTransactionBody is executed, the
 * network only charges its payer the service fee, and not the node and network fees. If the
 * optional payerAccountID is set, the network charges this account. Otherwise it charges
 * the payer of the originating ScheduleCreate.  
 * 
 * Two ScheduleCreate transactions are identical if they are equal in all their
 * fields other than payerAccountID.  (For the scheduledTransactionBody field,
 * "equal" should be understood in the sense of
 * gRPC object equality in the network software runtime. In particular, a gRPC object with unknown fields is
 * not equal to a gRPC object without unknown fields, even if they agree on all known fields.) 
 * 
 * A ScheduleCreate transaction that attempts to re-create an identical schedule already in
 * state will receive a receipt with status IDENTICAL_SCHEDULE_ALREADY_CREATED; the receipt
 * will include the ScheduleID of the extant schedule, which may be used in a subsequent
 * ScheduleSign transaction. (The receipt will also include the TransactionID to
 * use in querying for the receipt or record of the scheduled transaction.)
 * 
 * Other notable response codes include, INVALID_ACCOUNT_ID,
 * UNSCHEDULABLE_TRANSACTION, UNRESOLVABLE_REQUIRED_SIGNERS,
 * INVALID_SIGNATURE. For more information please see the section of this documentation on
 * the ResponseCode enum. 
 */
message ScheduleCreateTransactionBody {
  /**
   * The scheduled transaction
   */
  SchedulableTransactionBody scheduledTransactionBody = 1;

  /**
   * An optional memo with a UTF-8 encoding of no more than 100 bytes which does not contain the
   * zero byte
   */
  string memo = 2;

  /**
   * An optional Hedera key which can be used to sign a ScheduleDelete and remove the schedule
   */
  Key adminKey = 3;

  /**
   * An optional id of the account to be charged the service fee for the scheduled transaction at
   * the consensus time that it executes (if ever); defaults to the ScheduleCreate payer if not
   * given
   */
  AccountID payerAccountID = 4;

  /**
   * An optional timestamp for specifying when the transaction should be evaluated for execution and then expire.
   * Defaults to 30 minutes after the transaction's consensus timestamp.
   *
   * Note: This field is unused and forced to be unset until Long Term Scheduled Transactions are enabled - Transactions will always
   *       expire in 30 minutes if Long Term Scheduled Transactions are not enabled.
   */
  Timestamp expiration_time = 5;

  /**
   * When set to true, the transaction will be evaluated for execution at expiration_time instead
   * of when all required signatures are received.
   * When set to false, the transaction will execute immediately after sufficient signatures are received
   * to sign the contained transaction. During the initial ScheduleCreate transaction or via ScheduleSign transactions.
   *
   * Defaults to false.
   *
   * Setting this to false does not necessarily mean that the transaction will never execute at expiration_time.
   *  For Example - If the signature requirements for a Scheduled Transaction change via external means (e.g. CryptoUpdate)
   *  such that the Scheduled Transaction would be allowed to execute, it will do so autonomously at expiration_time, unless a
   *  ScheduleSign comes in to "poke" it and force it to go through immediately.
   *
   * Note: This field is unused and forced to be unset until Long Term Scheduled Transactions are enabled. Before Long Term
   *       Scheduled Transactions are enabled, Scheduled Transactions will _never_ execute at expiration  - they will _only_
   *       execute during the initial ScheduleCreate transaction or via ScheduleSign transactions and will _always_
   *       expire at expiration_time.
   */
  bool wait_for_expiry = 13;
}




© 2015 - 2024 Weber Informatics LLC | Privacy Policy