@bitgo/account-lib 3.0.0-hotfix.0 → 4.0.0

package/dist/resources/hbar/protobuf/BasicTypes.proto

@@ -1,424 +0,0 @@
-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.
- * ‍
- */
-
-import "Timestamp.proto";
-
-/* Each shard has a nonnegative shard number. Each realm within a given shard has a nonnegative realm number (that number might be reused in other shards). And each account, file, and smart contract instance within a given realm has a nonnegative number (which might be reused in other realms). Every account, file, and smart contract instance is within exactly one realm. So a FileID is a triplet of numbers, like 0.1.2 for entity number 2 within realm 1  within shard 0.  Each realm maintains a single counter for assigning numbers,  so if there is a file with ID 0.1.2, then there won't be an account or smart  contract instance with ID 0.1.2.
-
-  Everything is partitioned into realms so that each Solidity smart contract can  access everything in just a single realm, locking all those entities while it's  running, but other smart contracts could potentially run in other realms in  parallel. So realms allow Solidity to be parallelized somewhat, even though the  language itself assumes everything is serial. */
-message ShardID {
-    int64 shardNum = 1; //the shard number (nonnegative)
-}
-
-/* The ID for a realm. Within a given shard, every realm has a unique ID. Each account, file, and contract instance belongs to exactly one realm. */
-message RealmID {
-    int64 shardNum = 1; //The shard number (nonnegative)
-    int64 realmNum = 2; //The realm number (nonnegative)
-}
-
-/* The ID for an a cryptocurrency account  */
-message AccountID {
-    int64 shardNum = 1; //The shard number (nonnegative)
-    int64 realmNum = 2; //The realm number (nonnegative)
-    int64 accountNum = 3; //A nonnegative account number unique within its realm
-}
-
-/* The ID for a file  */
-message FileID {
-    int64 shardNum = 1; //The shard number (nonnegative)
-    int64 realmNum = 2; //The realm number (nonnegative)
-    int64 fileNum = 3; //A nonnegative File number unique within its realm
-}
-
-/* The ID for a smart contract instance  */
-message ContractID {
-    int64 shardNum = 1; //The shard number (nonnegative)
-    int64 realmNum = 2; //The realm number (nonnegative)
-    int64 contractNum = 3; //A nonnegative number unique within its realm
-}
-
-/*
-The ID for a transaction. This is used for retrieving receipts and records for a transaction, for appending to a file right after creating it, for instantiating a smart contract with bytecode in a file just created, and internally by the network for detecting when duplicate transactions are submitted. A user might get a transaction processed faster by submitting it to N nodes, each with a different node account, but all with the same TransactionID. Then, the transaction will take effect when the first of all those nodes submits the transaction and it reaches consensus. The other transactions will not take effect. So this could make the transaction take effect faster, if any given node might be slow. However, the full transaction fee is charged for each transaction, so the total fee is N times as much if the transaction is sent to N nodes.
-Applicable to Scheduled Transactions:
-- The ID of a Scheduled Transaction has transactionValidStart and accountIDs inherited from the ScheduleCreate transaction that created it. That is to say that they are equal
-- The scheduled property is true for Scheduled Transactions
-- transactionValidStart, accountID and scheduled properties should be omitted
-- Scheduled Transactions should be submitted with only nonce populated (if desired). Nonce is an additional option presented to users so that they can create multiple sequential Scheduled Transactions that have the same transaction body.
-*/
-message TransactionID {
-    Timestamp transactionValidStart = 1; // The transaction is invalid if consensusTimestamp < transactionID.transactionStartValid
-    AccountID accountID = 2; // The Account ID that paid for this transaction
-    bool scheduled = 3; // Whether the Transaction is of type Scheduled or no
-}
-
-/* An account, and the amount that it sends or receives during a cryptocurrency or token transfer. */
-message AccountAmount {
-    AccountID accountID = 1; // The Account ID that sends/receives cryptocurrency or tokens
-    sint64 amount = 2; // The amount of tinybars (for Crypto transfers) or in the lowest denomination (for Token transfers) that the account sends(negative) or receives(positive)
-}
-
-/* A list of accounts and amounts to transfer out of each account (negative) or into it (positive). */
-message TransferList {
-    repeated AccountAmount accountAmounts = 1; // Multiple list of AccountAmount pairs, each of which has an account and an amount to transfer into it (positive) or out of it (negative)
-}
-
-/* A list of token IDs and amounts representing the transferred out (negative) or into (positive) amounts, represented in the lowest denomination of the token */
-message TokenTransferList {
-    TokenID token = 1; // The ID of the token
-    repeated AccountAmount transfers = 2; // Multiple list of AccountAmounts, each of which has an account and amount
-}
-
-/* Unique identifier for a topic (used by the consensus service) */
-message TopicID {
-    int64 shardNum = 1; // The shard number (nonnegative)
-    int64 realmNum = 2; // The realm number (nonnegative)
-    int64 topicNum = 3; // Unique topic identifier within a realm (nonnegative).
-}
-
-/* Unique identifier for a token */
-message TokenID {
-    int64 shardNum = 1; // A nonnegative shard number
-    int64 realmNum = 2; // A nonnegative realm number
-    int64 tokenNum = 3; // A nonnegative token number
-}
-
-/* Unique identifier for a Schedule */
-message ScheduleID {
-    int64 shardNum = 1; // A nonnegative shard number
-    int64 realmNum = 2; // A nonnegative realm number
-    int64 scheduleNum = 3; // A nonnegative schedule number
-}
-
-/* Possible Freeze statuses returned on TokenGetInfoQuery or CryptoGetInfoResponse in TokenRelationship */
-enum TokenFreezeStatus {
-    FreezeNotApplicable = 0;
-    Frozen = 1;
-    Unfrozen = 2;
-}
-
-/* Possible KYC statuses returned on TokenGetInfoQuery or CryptoGetInfoResponse in TokenRelationship */
-enum TokenKycStatus {
-    KycNotApplicable = 0;
-    Granted = 1;
-    Revoked = 2;
-}
-
-/* A Key can be a public key from one of the three supported systems (ed25519, RSA-3072,  ECDSA with p384). Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. And similarly for RSA and ECDSA.
- *
- * A Key can be a smart contract ID, which means that smart contract is to authorize operations as if it had signed with a key that it owned. The smart contract doesn't actually have a key, and  doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key.
- *
- * A key can be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements.
- *
- * A Key can be a list of keys. Their use is dependent on context. For example, a Hedera file is created with a list of keys, where all of them must sign a transaction to create or modify the file, but only one of them is needed to sign a transaction to delete the file. So it's a single list that sometimes acts as a 1-of-M threshold key, and sometimes acts as an M-of-M threshold key.
- *
- * A Key can contain a ThresholdKey or KeyList, which in turn contain a Key, so this mutual recursion would allow nesting arbitrarily deep. A ThresholdKey which contains a list of primitive keys (e.g., ed25519) has 3 levels: ThresholdKey -> KeyList -> Key. A KeyList which contains several primitive keys (e.g., ed25519) has 2 levels: KeyList -> Key. A Key with 2 levels of nested ThresholdKeys has 7 levels: Key -> ThresholdKey -> KeyList -> Key -> ThresholdKey -> KeyList -> Key.
- *
- * Each Key should not have more than 46 levels, which implies 15 levels of nested ThresholdKeys.
- */
-message Key {
-    oneof key {
-        ContractID contractID = 1; // smart contract instance that is authorized as if it had signed with a key
-        bytes ed25519 = 2; // ed25519 public key bytes
-        bytes RSA_3072 = 3; // RSA-3072 public key bytes
-        bytes ECDSA_384 = 4; // ECDSA with the p-384 curve public key bytes
-        ThresholdKey thresholdKey = 5; // a threshold N followed by a list of M keys, any N of which are required to form a valid signature
-        KeyList keyList = 6; // A list of Keys of the Key type.
-    }
-}
-
-/* A set of public keys that are used together to form a threshold signature. If the threshold is N and there are M keys, then this is an N of M threshold signature. If an account is associated with ThresholdKeys, then a transaction to move cryptocurrency out of it must be signed by a list of M signatures, where at most M-N of them are blank, and the other at least N of them are valid signatures corresponding to at least N of the public keys listed here. */
-message ThresholdKey {
-    uint32 threshold = 1; // A valid signature set must have at least this many signatures
-    KeyList keys = 2; // List of all the keys that can sign
-}
-
-/* A list of keys */
-message KeyList {
-    repeated Key keys = 1; // list of keys
-}
-
-/* A Signature corresponding to a Key. It is a sequence of bytes holding a public key signature from one of the three supported systems (ed25519, RSA-3072,  ECDSA with p384). Or, it can be a list of signatures corresponding to a single threshold key. Or, it can be the ID of a smart contract instance, which is authorized to act as if it had a key. If an account has an ed25519 key associated with it, then the corresponding private key must sign any transaction to transfer cryptocurrency out of it. If it has a smart contract ID associated with it, then that smart contract is allowed to transfer cryptocurrency out of it. The smart contract doesn't actually have a key, and  doesn't actually sign a transaction. But it's as if a virtual transaction were created, and the smart contract signed it with a private key. A key can also be a "threshold key", which means a list of M keys, any N of which must sign in order for the threshold signature to be considered valid. The keys within a threshold signature may themselves be threshold signatures, to allow complex signature requirements (this nesting is not supported in the currently, but will be supported in a future version of API). If a Signature message is missing the "signature" field, then this is considered to be a null signature. That is useful in cases such as threshold signatures, where some of the signatures can be null.
- * The definition of Key uses mutual recursion, so it allows nesting that is arbitrarily deep. But the current API only accepts Key messages up to 3 levels deep, such as a list of threshold keys, each of which is a list of primitive keys. Therefore, the matching Signature will have the same limitation. This restriction may be relaxed in future versions of the API, to allow deeper nesting.
- * This message is deprecated and succeeded by SignaturePair and SignatureMap messages.
- */
-message Signature {
-    option deprecated = true;
-    oneof signature {
-        bytes contract = 1; // smart contract virtual signature (always length zero)
-        bytes ed25519 = 2; // ed25519 signature bytes
-        bytes RSA_3072 = 3; //RSA-3072 signature bytes
-        bytes ECDSA_384 = 4; //ECDSA p-384 signature bytes
-        ThresholdSignature thresholdSignature = 5; // A list of signatures for a single N-of-M threshold Key. This must be a list of exactly M signatures, at least N of which are non-null.
-        SignatureList signatureList = 6; // A list of M signatures, each corresponding to a Key in a KeyList of the same length.
-    }
-}
-
-/*
-A signature corresponding to a ThresholdKey. For an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null.
-This message is deprecated and succeeded by SignaturePair and SignatureMap messages.
-*/
-message ThresholdSignature {
-    option deprecated = true;
-    SignatureList sigs = 2; // for an N-of-M threshold key, this is a list of M signatures, at least N of which must be non-null
-}
-
-/*
-The signatures corresponding to a KeyList of the same length.
-This message is deprecated and succeeded by SignaturePair and SignatureMap messages.
-*/
-message SignatureList {
-    option deprecated = true;
-    repeated Signature sigs = 2; // each signature corresponds to a Key in the KeyList
-}
-
-/*
-The client may use any number of bytes from 0 to the whole length of the public key for pubKeyPrefix.
-If 0 bytes is used, then it is assumed that only one public key is used to sign.
-*/
-message SignaturePair {
-    bytes pubKeyPrefix = 1; // First few bytes of the public key
-    oneof signature {
-        bytes contract = 2; // smart contract virtual signature (always length zero)
-        bytes ed25519 = 3; // ed25519 signature
-        bytes RSA_3072 = 4; //RSA-3072 signature
-        bytes ECDSA_384 = 5; //ECDSA p-384 signature
-    }
-}
-
-/*
-A set of signatures corresponding to every unique public key used to sign a given transaction. If one public key matches more than one prefixes on the signature map, the transaction containing the map will fail immediately with the response code KEY_PREFIX_MISMATCH.
-*/
-message SignatureMap {
-    repeated SignaturePair sigPair = 1; // Each signature pair corresponds to a unique Key required to sign the transaction.
-}
-
-/*
-The transactions and queries supported by Hedera Hashgraph.
-*/
-enum HederaFunctionality {
-    NONE = 0; // UNSPECIFIED - Need to keep first value as unspecified because first element is ignored and not parsed (0 is ignored by parser)
-    CryptoTransfer = 1; // crypto transfer
-    CryptoUpdate = 2; // crypto update account
-    CryptoDelete = 3; // crypto delete account
-    // Add a livehash to a crypto account
-    CryptoAddLiveHash = 4;
-    // Delete a livehash from a crypto account
-    CryptoDeleteLiveHash = 5;
-    ContractCall = 6; // Smart Contract Call
-    ContractCreate = 7; // Smart Contract Create Contract
-    ContractUpdate = 8; // Smart Contract update contract
-    FileCreate = 9; // File Operation create file
-    FileAppend = 10; // File Operation append file
-    FileUpdate = 11; // File Operation update file
-    FileDelete = 12; // File Operation delete file
-    CryptoGetAccountBalance = 13; // crypto get account balance
-    CryptoGetAccountRecords = 14; // crypto get account record
-    CryptoGetInfo = 15; // Crypto get info
-    ContractCallLocal = 16; // Smart Contract Call
-    ContractGetInfo = 17; // Smart Contract get info
-    ContractGetBytecode = 18; // Smart Contract, get the byte code
-    GetBySolidityID = 19; // Smart Contract, get by solidity ID
-    GetByKey = 20; // Smart Contract, get by key
-    // Get a live hash from a crypto account
-    CryptoGetLiveHash = 21;
-    CryptoGetStakers = 22; // Crypto, get the stakers for the node
-    FileGetContents = 23; // File Operations get file contents
-    FileGetInfo = 24; // File Operations get the info of the file
-    TransactionGetRecord = 25; // Crypto get the transaction records
-    ContractGetRecords = 26; // Contract get the transaction records
-    CryptoCreate = 27; // crypto create account
-    SystemDelete = 28; // system delete file
-    SystemUndelete = 29; // system undelete file
-    ContractDelete = 30; // delete contract
-    Freeze = 31; // freeze
-    CreateTransactionRecord = 32; // Create Tx Record
-    CryptoAccountAutoRenew = 33; // Crypto Auto Renew
-    ContractAutoRenew = 34; // Contract Auto Renew
-    GetVersionInfo = 35; //Get Version
-    TransactionGetReceipt = 36; // Transaction Get Receipt
-    ConsensusCreateTopic = 50; // Create Topic
-    ConsensusUpdateTopic = 51; // Update Topic
-    ConsensusDeleteTopic = 52; // Delete Topic
-    ConsensusGetTopicInfo = 53; // Get Topic information
-    ConsensusSubmitMessage = 54; // Submit message to topic
-    UncheckedSubmit = 55;
-    TokenCreate = 56; // Create Token
-    TokenGetInfo = 58; // Get Token information
-    TokenFreezeAccount = 59; // Freeze Account
-    TokenUnfreezeAccount = 60; // Unfreeze Account
-    TokenGrantKycToAccount = 61; // Grant KYC to Account
-    TokenRevokeKycFromAccount = 62; // Revoke KYC from Account
-    TokenDelete = 63; // Delete Token
-    TokenUpdate = 64; // Update Token
-    TokenMint = 65; // Mint tokens to treasury
-    TokenBurn = 66; // Burn tokens from treasury
-    TokenAccountWipe = 67; // Wipe token amount from Account holder
-    TokenAssociateToAccount = 68; // Associate tokens to an account
-    TokenDissociateFromAccount = 69; // Dissociate tokens from an account
-    ScheduleCreate = 70; // Create Scheduled Transaction
-    ScheduleDelete = 71; // Delete Scheduled Transaction
-    ScheduleSign = 72; // Sign Scheduled Transaction
-    ScheduleGetInfo = 73; // Get Scheduled Transaction Information
-}
-
-/*
-A set of prices the nodes use in determining transaction and query fees, and constants involved in fee calculations.
-Nodes multiply the amount of resources consumed by a transaction or query by the corresponding price to calculate the
-appropriate fee. Units are one-thousandth of a tinyCent.*/
-message FeeComponents {
-    int64 min = 1; // A minimum, the calculated fee must be greater than this value
-    int64 max = 2; // A maximum, the calculated fee must be less than this value
-    int64 constant = 3; // A constant contribution to the fee
-    int64 bpt = 4; // The price of bandwidth consumed by a transaction, measured in bytes
-    int64 vpt = 5; // The price per signature verification for a transaction
-    int64 rbh = 6; // The price of RAM consumed by a transaction, measured in byte-hours
-    int64 sbh = 7; // The price of storage consumed by a transaction, measured in byte-hours
-    int64 gas = 8; // The price of computation for a smart contract transaction, measured in gas
-    int64 tv = 9; // The price per hbar transferred for a transfer
-    int64 bpr = 10; // The price of bandwidth for data retrieved from memory for a response, measured in bytes
-    int64 sbpr = 11; // The price of bandwidth for data retrieved from disk for a response, measured in bytes
-}
-
-/* The fees for a specific transaction or query based on the fee data. */
-message TransactionFeeSchedule {
-    // A particular transaction or query
-    HederaFunctionality hederaFunctionality = 1;
-    // Resource price coefficients
-    FeeData feeData = 2;
-}
-
-/*
-The total fee charged for a transaction. It is composed of three components – a node fee that compensates the specific node that submitted the transaction, a network fee that compensates the network for assigning the transaction a consensus timestamp, and a service fee that compensates the network for the ongoing maintenance of the consequences of the transaction.
-*/
-message FeeData {
-    // Fee paid to the submitting node
-    FeeComponents nodedata = 1;
-    // Fee paid to the network for processing a transaction into consensus
-    FeeComponents networkdata = 2;
-    // Fee paid to the network for providing the service associated with the transaction; for instance, storing a file
-    FeeComponents servicedata = 3;
-}
-
-/*
-A list of resource prices fee for different transactions and queries and the time period at which this fee schedule will expire. Nodes use the prices to determine the fees for all transactions based on how much of those resources each transaction uses.
-*/
-message FeeSchedule {
-    // List of price coefficients for network resources
-    repeated TransactionFeeSchedule transactionFeeSchedule = 1;
-    // FeeSchedule expiry time
-    TimestampSeconds expiryTime = 2;
-}
-
-/* This contains two Fee Schedules with expiry timestamp. */
-message CurrentAndNextFeeSchedule {
-    FeeSchedule currentFeeSchedule = 1; // Contains current Fee Schedule
-    FeeSchedule nextFeeSchedule = 2; // Contains next Fee Schedule
-}
-
-/* This contains the IP Address and the port representing an endpoint of a Node in a network */
-message NodeEndpoint {
-    string ipAddress = 1; // The IP address of the node
-    string port = 2; // The port of the node
-}
-
-/*
-The metadata for a Node – including IP Address, and the crypto account associated with the Node.
-
-Note :  This structure is intended to be used to parse 0.0.102, use NodeAddressForClients to parse 0.0.101.
-        Usage of NodeAddress to parse 0.0.101 is deprecated.
-*/
-message NodeAddress {
-    bytes ipAddress = 1 [deprecated=true]; // The ip address of the Node with separator & octets. Usage is deprecated, NodeEndPoint is preferred to retrieve a node's list of IP addresses and ports
-    int32 portno = 2 [deprecated=true]; // The port number of the grpc server for the node.  Usage is deprecated, NodeEndPoint is preferred to retrieve a node's list of IP addresses and ports
-    bytes memo = 3 [deprecated=true]; // Usage is deprecated, nodeAccountId is preferred to retrieve a node's account ID
-    string RSA_PubKey = 4; // The RSA public key of the node
-    int64 nodeId = 5; // A non-sequential identifier for the node
-    AccountID nodeAccountId = 6; // The account to be paid for queries and transactions sent to this node
-    bytes nodeCertHash = 7; // A hash of the X509 cert used for gRPC traffic to this node
-    repeated NodeEndpoint nodeEndpoint = 8; // A node's IP address and port
-    string description = 9; // A description of the node. Max 100 bytes.
-    int64 stake = 10; // The amount of tinybars staked to this node
-}
-
-/*
-A list of nodes and their metadata that contains all details of the nodes for the network
-*/
-message AddressBook {
-    repeated NodeAddress nodeAddress = 1; // Metadata of nodes on the network
-}
-
-/* All the information required to connect to the network.*/
-message NodeAddressForClients {
-    int64 nodeId = 5; // A non-sequential identifier for the node. This value is the key between the full and abbreviated address books
-    AccountID nodeAccountId = 6; // The account to be paid for queries and transactions sent to this node
-    bytes nodeCertHash = 7; // A hash of the X509 cert used for gRPC traffic to this node
-    repeated NodeEndpoint nodeEndpoint = 8; // A node's IP address and port
-}
-
-/* A List of all nodes and just their information needed to connect to the network.*/
-message AddressBookForClients {
-    repeated NodeAddressForClients nodeAddressForClients = 1; // Contains minimal node details for the network
-}
-
-message SemanticVersion {
-    int32 major = 1; // Increases with incompatible API changes
-    int32 minor = 2; // Increases with backwards-compatible new functionality
-    int32 patch = 3; // Increases with backwards-compatible bug fixes
-}
-
-message Setting {
-    string name = 1; // name of the property
-    string value = 2; // value of the property
-    bytes data = 3; // any data associated with property
-}
-
-message ServicesConfigurationList {
-    repeated Setting nameValue = 1; // list of name value pairs of the application properties
-}
-
-/* Token's information related to the given Account */
-message TokenRelationship {
-    TokenID tokenId = 1; // The ID of the token
-    string symbol = 2; // The Symbol of the token
-    uint64 balance = 3; // The balance that the Account holds in the smallest denomination
-    TokenKycStatus kycStatus = 4; // The KYC status of the account (KycNotApplicable, Granted or Revoked). If the token does not have KYC key, KycNotApplicable is returned
-    TokenFreezeStatus freezeStatus = 5; // The Freeze status of the account (FreezeNotApplicable, Frozen or Unfrozen). If the token does not have Freeze key, FreezeNotApplicable is returned
-    uint32 decimals = 6; // Tokens divide into <tt>10<sup>decimals</sup></tt> pieces
-}
-
-/* A number of <i>transferable units</i> of a certain token.
-
-The transferable unit of a token is its smallest denomination, as given by the token's <tt>decimals</tt> property---each minted token contains <tt>10<sup>decimals</sup></tt> transferable units. For example, we could think of the cent as the transferable unit of the US dollar (<tt>decimals=2</tt>); and the tinybar as the transferable unit of hbar (<tt>decimals=8</tt>).
-
-Transferable units are not directly comparable across different tokens. */
-message TokenBalance {
-    TokenID tokenId = 1; // A unique token id
-    uint64 balance = 2; // A number of transferable units of the identified token
-    uint32 decimals = 3; // Tokens divide into <tt>10<sup>decimals</sup></tt> pieces
-}
-
-/* A sequence of token balances */
-message TokenBalances {
-    repeated TokenBalance tokenBalances = 1;
-}

package/dist/resources/hbar/protobuf/CryptoCreate.proto

@@ -1,47 +0,0 @@
-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.
- * ‍
- */
-
-import "BasicTypes.proto";
-import "Duration.proto";
-
-/*
-Create a new account. After the account is created, the AccountID for it is in the receipt. It can also be retrieved with a GetByKey query. Threshold values can be defined, and records are generated and stored for 25 hours for any transfer that exceeds the thresholds. This account is charged for each record generated, so the thresholds are useful for limiting record generation to happen only for large transactions.
-
-The Key field is the key used to sign transactions for this account. If the account has receiverSigRequired set to true, then all cryptocurrency transfers must be signed by this account's key, both for transfers in and out. If it is false, then only transfers out have to be signed by it. When the account is created, the payer account is charged enough hbars so that the new account will not expire for the next autoRenewPeriod seconds. When it reaches the expiration time, the new account will then be automatically charged to renew for another autoRenewPeriod seconds. If it does not have enough hbars to renew for that long, then the remaining hbars are used to extend its expiration as long as possible. If it is has a zero balance when it expires, then it is deleted. This transaction must be signed by the payer account. If receiverSigRequired is false, then the transaction does not have to be signed by the keys in the keys field. If it is true, then it must be signed by them, in addition to the keys of the payer account.
-An entity (account, file, or smart contract instance) must be created in a particular realm. If the realmID is left null, then a new realm will be created with the given admin key. If a new realm has a null adminKey, then anyone can create/modify/delete entities in that realm. But if an admin key is given, then any transaction to create/modify/delete an entity in that realm must be signed by that key, though anyone can still call functions on smart contract instances that exist in that realm. A realm ceases to exist when everything within it has expired and no longer exists.
-The current API ignores shardID, realmID, and newRealmAdminKey, and creates everything in shard 0 and realm 0, with a null key. Future versions of the API will support multiple realms and multiple shards.
- */
-message CryptoCreateTransactionBody {
-    Key key = 1; // The key that must sign each transfer out of the account. If receiverSigRequired is true, then it must also sign any transfer into the account.
-    uint64 initialBalance = 2; // The initial number of tinybars to put into the account
-    AccountID proxyAccountID = 3; // ID of the account to which this account is proxy staked. If proxyAccountID is null, or is an invalid account, or is an account that isn't a node, then this account is automatically proxy staked to a node chosen by the network, but without earning payments. If the proxyAccountID account refuses to accept proxy staking , or if it is not currently running a node, then it will behave as if proxyAccountID was null.
-    uint64 sendRecordThreshold = 6 [deprecated=true]; // [Deprecated]. The threshold amount (in tinybars) for which an account record is created for any send/withdraw transaction
-    uint64 receiveRecordThreshold = 7 [deprecated=true]; // [Deprecated]. The threshold amount (in tinybars) for which an account record is created for any receive/deposit transaction
-    bool receiverSigRequired = 8; // If true, this account's key must sign any transaction depositing into this account (in addition to all withdrawals)
-    Duration autoRenewPeriod = 9; // The account is charged to extend its expiration date every this many seconds. If it doesn't have enough balance, it extends as long as possible. If it is empty when it expires, then it is deleted.
-    ShardID shardID = 10; // The shard in which this account is created
-    RealmID realmID = 11; // The realm in which this account is created (leave this null to create a new realm)
-    Key newRealmAdminKey = 12; // If realmID is null, then this the admin key for the new realm that will be created
-    string memo = 13; // The memo associated with the account (UTF-8 encoding max 100 bytes)
-}

package/dist/resources/hbar/protobuf/CryptoTransfer.proto

@@ -1,33 +0,0 @@
-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.
- * ‍
- */
-
-import "BasicTypes.proto";
-
-/* Transfer cryptocurrency from some accounts to other accounts. The accounts list can contain up to 10 accounts. The amounts list must be the same length as the accounts list. Each negative amount is withdrawn from the corresponding account (a sender), and each positive one is added to the corresponding account (a receiver). The amounts list must sum to zero. Each amount is a number of tinyBars (there are 100,000,000 tinyBars in one Hbar).
-If any sender account fails to have sufficient hbars, then the entire transaction fails, and none of those transfers occur, though the transaction fee is still charged. This transaction must be signed by the keys for all the sending accounts, and for any receiving accounts that have receiverSigRequired == true. The signatures are in the same order as the accounts, skipping those accounts that don't need a signature.
-*/
-message CryptoTransferTransactionBody {
-    TransferList transfers = 1;
-    repeated TokenTransferList tokenTransfers = 2;
-}

package/dist/resources/hbar/protobuf/Duration.proto

@@ -1,28 +0,0 @@
-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.
- * ‍
- */
-
-/* A length of time in seconds. */
-message Duration {
-    int64 seconds = 1; // The number of seconds
-}

package/dist/resources/hbar/protobuf/Timestamp.proto

@@ -1,34 +0,0 @@
-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.
- * ‍
- */
-
-/* An exact date and time. This is the same data structure as the protobuf Timestamp.proto (see the comments in https://github.com/google/protobuf/blob/master/src/google/protobuf/timestamp.proto) */
-message Timestamp {
-    int64 seconds = 1; // Number of complete seconds since the start of the epoch
-    int32 nanos = 2; // Number of nanoseconds since the start of the last second
-}
-
-/* An exact date and time,  with a resolution of one second (no nanoseconds). */
-message TimestampSeconds {
-    int64 seconds = 1; // Number of complete seconds since the start of the epoch
-}

package/dist/resources/hbar/protobuf/Transaction.proto

@@ -1,35 +0,0 @@
-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.
- * ‍
- */
-
-import "Duration.proto";
-import "BasicTypes.proto";
-
-/* A single signed transaction, including all its signatures. The SignatureList will have a Signature for each Key in the transaction, either explicit or implicit, in the order that they appear in the transaction. For example, a CryptoTransfer will first have a Signature corresponding to the Key for the paying account, followed by a Signature corresponding to the Key for each account that is sending or receiving cryptocurrency in the transfer. Each Transaction should not have more than 50 levels.
- * The SignatureList field is deprecated and succeeded by SignatureMap.
- */
-message Transaction {
-    bytes signedTransactionBytes = 5; // SignedTransaction serialized into bytes
-    bytes bodyBytes = 4 [deprecated = true]; // TransactionBody serialized into bytes, which needs to be signed
-    SignatureMap sigMap = 3 [deprecated = true]; // The signatures on the body with the new format, to authorize the transaction
-}

package/dist/resources/hbar/protobuf/TransactionBody.proto

@@ -1,24 +0,0 @@
-syntax = "proto3";
-
-package proto;
-
-import "CryptoCreate.proto";
-import "CryptoTransfer.proto";
-import "Duration.proto";
-import "BasicTypes.proto";
-
-
-/* A single transaction. All transaction types are possible here. */
-message TransactionBody {
-  TransactionID transactionID = 1; // The ID for this transaction, which includes the payer's account (the account paying the transaction fee). If two transactions have the same transactionID, they won't both have an effect
-  AccountID nodeAccountID = 2; // The account of the node that submits the client's transaction to the network
-  uint64 transactionFee = 3; // The maximum transaction fee the client is willing to pay
-  Duration transactionValidDuration = 4; //The transaction is invalid if consensusTimestamp > transactionID.transactionValidStart + transactionValidDuration
-  bool generateRecord = 5 [deprecated = true]; // Should a record of this transaction be generated? (A receipt is always generated, but the record is optional)
-  string memo = 6; // Any notes or descriptions that should be put into the record (max length 100)
-  oneof data {
-    CryptoCreateTransactionBody cryptoCreateAccount = 11; // Create a new cryptocurrency account
-    CryptoTransferTransactionBody cryptoTransfer = 14; // Transfer amount between accounts
-
-  }
-}